Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]! >> 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, Which is not necessarily related to the permissions on the file. Windows socket is an in-memory object, the file is used merely for naming purposes. > so permissions should be working for these objects (otherwise, there's no > other way!) Does the not? Can you connect to a socket with user that should not have permissions after you have changed them? > And fchmod() for a bound Unix socket works on Linux and many other Unix > flavors, actually. "Works", all right. But HOW does it works? Aren't the permissions seen on the socket file merely a coincidence/convenience? -- With best regards, Andrey Repin Sunday, July 3, 2022 00:57:58 Sorry for my terrible english... -- 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
