blblack/zig:unix-listen-perms into master
This optionally sets the initial permissions on a UnixAddress
listener socket fd before the bind() call creates the file,
avoiding the potential security race if the application did so
after netListenUnix() returns.
This optionally sets the initial permissions on a UnixAddress listener socket fd before the `bind()` call creates the file, avoiding the potential security race if the application did so after `netListenUnix()` returns.
9ee240aad3
cc46cb9acf
Thanks!
(I'll want to have another look after the CI is passing)
cc46cb9acf
690997680f
@andrewrk - The problem I'm running into here now is that some platforms fail if you try to set permissions this way. It's just not as universally-supported as I expected it to be!
Works: Linux, FreeBSD, apparently Windows (at least, it doesn't error out)
Fails: MacOS, and I now think OpenBSD and NetBSD will too
Unknown: All the rest
They fail because they simply don't support fchmod() on a unix socket descriptor and will return EINVAL or similar. For such platforms, the only way to handle this (AFAIK) is the racy method of doing it after the bind(), probably with a separately-opened regular file descriptor on the same path (or, I guess, you could alter the process-global umask around the bind(), but that's racy for threads on another level).
There's a few potential ways I can see to handle this situation and still have the option. The top two on my mind are:
.permissions = .default_file on select known-good platforms so that CI passes. It will be basically up to the application layer to decide if they care about this and to care about which platforms they handle race-free (via this option) or in a racy way (in their application code).netListenUnix(): only handle it race-free where it's known to work, and then do it the racy way for the caller in other cases at the bottom with another few syscalls, and document that the option only makes it race-free where that's even possible.Thoughts?
... or of course, I should add:
0o022), meaning the default perms of the socket will only allow connections from the same uid as ourselves, which makes changing it later not be a security race from most perspectives.Mostly the root of this whole problem is the process-global-umask problem. You could argue that applications which care about unix listening socket perms should enforce an appropriate umask early during main() before any threading issues arise and leave it that way? There will be edge cases where other parts of the code needs a more-permissive umask than the unix listening socket, but those edge cases could be punted as "your case is too-special to support".
There's similar issues around owner/group for the socket file, but changing that is only realistic if running as root, usually, and so again it's kind of out there from the norm.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?