RE: Weird issue with file permissions

RE: Weird issue with file permissions

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

I forgot to mention that my "umask" is the standard 022...

The man page says that for directories with the ACLs, it is ignored.

So in my code bind() wouldn't have created the socket with 0777, and
that's fine!  Which is why I call fchmod() to fix the permissions up,
and THAT does not work.  BTW, should I have called chmod() instead (which
is what the command line chmod does), the permissions would have been
set correctly on the socket file, but fchmod() would have misreported
them again (this time looks like a carryover from an earlier umask(0))!

$ diff sun1.c sun.c
37c37
<     if (chmod(SOCKET, 0666) < 0)
---
>     if (fchmod(s, 0666) < 0)

$ pwd 
/cygdrive/g/cygwin
$ mkdir subdir
$ cd subdir
$ ~/sun1
fstat mode = 140777
stat mode = 140666
$ ls -la
total 17
drwxrwxr-x+ 1 ANTON None 0 Jul  2 12:06 ./
drwxrwx---+ 1 ANTON None 0 Jul  2 12:06 ../
srw-rw-rw-+ 1 ANTON None 0 Jul  2 12:06 .socket=

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: Weird issue with file permissions

[Ken Brown]

On 7/2/2022 12:16 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> I forgot to mention that my "umask" is the standard 022...
> 
> The man page says that for directories with the ACLs, it is ignored.
> 
> So in my code bind() wouldn't have created the socket with 0777, and
> that's fine!  Which is why I call fchmod() to fix the permissions up,
> and THAT does not work.  BTW, should I have called chmod() instead (which
> is what the command line chmod does), the permissions would have been
> set correctly on the socket file, but fchmod() would have misreported
> them again (this time looks like a carryover from an earlier umask(0))!

I was focused on ACLs in my earlier responses and didn't think hard enough about 
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 
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/fchmod.html#tag_16_119).

Ken

RE: [EXTERNAL] Re: Weird issue with file permissions

[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,
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.

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: [EXTERNAL] Re: Weird issue with file permissions

[Ken Brown]

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

Re: [EXTERNAL] Re: Weird issue with file permissions

[Andrey Repin]

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...