Unix socket mode not set to 0o777

[hvenev]

Currently, cheroot deletes any pre-existing AF_UNIX socket file, then attempts to chmod the now non-existent file to 0o777, and only then creates it.

The correct behaviour would be to chmod the socket after creating it.

[webknjaz]

Thanks for pointing this out. Feel free to send a PR for that.

[webknjaz]

Hm.. It was there from the very beginning: 6ced9fd#diff-920de15fced9e5f9697efed08f3c207dR214

[webknjaz]

@hvenev feel free to review #110

[hvenev]

This is certainly an improvement over the old behaviour.

Interestingly, the old behaviour also had a security vulnerability: If cherrypy is running as root and the socket is in /tmp/, a process might put a symlink to a system file between the unlink and the chmod, and trick cherrypy into making the file writeable.

Now chmod() only happens after we're certain the file has been created by us. Assuming another user can't delete/move the socket and put something else in its place (which is forbidden for /tmp), this should no longer be a problem.

Still, if you're feeling paranoid, you might want to set os.chmod(..., follow_symlinks=False). This helps if the socket is in a directory owned by an untrusted user (which is in general very hard to get secure).

While writing this, I found a better option: call chmod on the socket before bind:

os.fchmod(socket.fileno(), 0o777)
socket.bind(path)

In this case bind() will create a socket file with mode 777 without having to fix it later.

Edit: the fchmod thing only works on Linux but not, for example, on macOS and FreeBSD.

Further edit: os.chmod(follow_symlinks=False) is not supported on Linux, but is supported on FreeBSD. I'm not sure about other platforms.

[webknjaz]

@hvenev thanks for the feedback! Please write the further reviews on PR page to help track all related info in one place :)

I'll think how we could combine the info you provided into patch improvement.

[webknjaz]

Another interesting post: python/asyncio#426 (comment)