On 7/2/2022 3:37 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
what your test program was actually doing. But you seem to be assuming that
calling fchmod on a socket descriptor should affect the permissions on the
socket file (assuming the socket is bound). Is that documented anywhere? POSIX
says that the behavior of fchmod on a socket descriptor is unspecified
The socket file descriptor for a bound UNIX sockets refers to an object in a
filesystem
(it's practically a file), which the bind() system call creates. The access to
the socket
is controlled by the permission bits, when someone actually tries to connect to
it,
so permissions should be working for these objects (otherwise, there's no other
way!)
And fchmod() for a bound Unix socket works on Linux and many other Unix
flavors, actually.
That's not what I'm seeing when I run your test program on Linux:
$ ./sun
fstat mode = 140666
stat mode = 140777
$ ls -l .socket
srwxrwxrwx. 1 kbrown kbrown 0 Jul 2 17:47 .socket=
So calling fchmod on the socket descriptor did not change the permissions of the
file to which the socket was bound.
And on freeBSD, calling fchmod on a socket descriptor is apparently an error:
https://www.freebsd.org/cgi/man.cgi?query=fchmod&sektion=2&n=1
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple