RE: Weird issue with file permissions

RE: Weird issue with file permissions

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

> That way I'm sure I won't have any surprises with permissions when working in
> /cygdrive/g/cygwin.  Do you want to try that and see if it makes a difference?

I have no problems with /cygdrive/g/cygwin -- my socket file gets created there with proper
permissions and reported so, too (both fstat and stat).

I have problems with the socket file that gets created under any subdirectory of that
directory IFF that subdirectory was created from under Cygwin (!) -- like with a shell command.
Creating the socket file in a subdirectory created by Windows works!  Isn't that weird?

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: Weird issue with file permissions

[Ken Brown]

On 7/1/2022 11:23 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> That way I'm sure I won't have any surprises with permissions when working in
>> /cygdrive/g/cygwin.  Do you want to try that and see if it makes a difference?
> 
> I have no problems with /cygdrive/g/cygwin -- my socket file gets created there with proper
> permissions and reported so, too (both fstat and stat).

Right, I understood that.  But the (default) ACL on that directory influences 
the ACL on subdirectories that are created. And there's also interaction between 
the default ACL and the umask 
(https://man7.org/linux/man-pages/man2/umask.2.html).  So I think it couldn't 
hurt to try my suggestion and then see if you continue to see weird behavior on 
newly created subdirectories.

I just tried this myself on an external hard drive on which I've never touched 
the permissions on the top-level directory.  I do see some weirdness (though not 
as extreme as yours), and the weirdness goes away when I change the ACL as I 
suggested you do.  Here's what I see.  [Note: I use /mnt as the cygdrive prefix.]

$ pwd
/mnt/d

$ getfacl .
# file: .
# owner: Administrators
# group: Unknown+Group
user::---
group::rwx              #effective:---
group:SYSTEM:rwx        #effective:---
mask::---
other::rwx
default:user::rwx
default:group::---
default:group:SYSTEM:rwx        #effective:---
default:mask::---
default:other::rwx

$ mkdir cygwin

$ cd cygwin/

$ getfacl .
# file: .
# owner: kbrown
# group: None
user::rwx
group::r-x
group:SYSTEM:rwx        #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:SYSTEM:rwx        #effective:r-x
default:mask::r-x
default:other::rwx

$ ./sun
fstat mode = 140666
stat mode = 140646

$ ls -l .socket
srw-r--rw- 1 kbrown None 0 2022-07-02 09:47 .socket=

$ mkdir sub

$ cd sub

$ ../sun.exe
fstat mode = 140666
stat mode = 140646

$ ls -l .socket
srw-r--rw- 1 kbrown None 0 2022-07-02 09:49 .socket=

$ cd ..

$ getfacl ~ | setfacl -f - .

$ getfacl .
# file: .
# owner: kbrown
# group: None
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

$ mkdir sub1

$ cd sub1

$ ../sun.exe
fstat mode = 140666
stat mode = 140666

$ ll .socket
srw-rw-rw- 1 kbrown None 0 2022-07-02 10:04 .socket=

Note that stat and fstat disagreed at first but then agreed after I put a 
standard ACL on the cygwin directory.

Having said all that, I still want to look into why stat and fstat disagree.

Ken

RE: Weird issue with file permissions

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

> That's not what I'm seeing when I run your test program on Linux:
> 
> $ ./sun
> fstat mode = 140666
> stat mode = 140777

True, but it creates the socket file with exactly how umask(0) told it to,
and stat() shows that.  So yeah, I should retract that it works on Linux with
fchmod() -- on Linux the fchmod() call won't be at all necessary.  And I just
checked BSD and MacOS, too.  [Truly, it's an old code that used to work everywhere
but failed on Cygwin -- that's how I noticed, so I assumed it was because of
fchmod() -- but it actually because of umask(0).]

On Cygwin, however, I have to resort to good old chmod().

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

Sockets are in-memory objects everywhere.  The UNIX socket file is a just connection
"point" (much like devices and other special files) that has to have proper permissions
for an accessor to be able to connect / read / etc.  The permissions are checked first,
then everything else goes.  So if a socket file in the filesystem isn't "readable"
for your permission category, you won't be able to connect regardless of what the
in-memory things are, IIRC.

> "Works", all right. But HOW does it works? Aren't the permissions seen on the
> socket file merely a coincidence/convenience?

No, they are NOT.  They are actually granting / denying the access.

Anyways, I think that I know how to fix this.  As to whether or not Cygwin must be
brought in line with Linux -- I can't tell, because I don't have files with ACLs
on Linux, so I can't see how umask(0), when ignored, would screw permissions there...

Anton Lavrentiev
Contractor NIH/NLM/NCBI

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: Weird issue with file permissions

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

> Cygwin does not do this on a standard installation.  Is it something you've done

I did use the standard Setup and nothing else...  My $HOME looks fine, too:

$ cd
$ pwd
/home/ANTON
$ getfacl .
# file: .
# owner: ANTON
# group: None
user::rwx
group::---
other::---
default:user::rwx
default:group::r-x
default:other::r-x
$ id
uid=197609(ANTON) gid=197121(None) groups=197121(None),559(Performance Log Users),545(Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated Users),15(This Organization),113(Local account),4095(CurrentSession),66048(LOCAL),262154(NTLM Authentication),401408(Medium Mandatory Level)

Whatever is on drive G: was mostly also created by Cygwin -- I was just simply moving stuff from
$HOME to there using tar (IIRC)...  Initially, it was a clean and empty NTFS volume (brand new).
So it was something like:

$ mkdir /cygdrive/g/cygwin

and then for each $stuffdir I wanted moved

$ cd; tar cf - ./$stuffdir | (cd /cygdrive/g/cygwin; tar xvf -)

So, I have no idea why permissions there ended up all perplexed.
But please note that .socket gets created perfectly fine in that directory,
yet the problem occurs when that's a subdirectory, created from under Cygwin!
(and again, all's fine if mkdir for the subdir is done by Windows)

$ cd /cygdrive/g/cygwin
$ getfacl .
# file: .
# owner: ANTON
# group: None
user::rwx
group::---
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask::rwx
other::---
default:user::---
default:group::---
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask::rwx
default:other::---

Re: Weird issue with file permissions

[Ken Brown]

On 7/1/2022 6:11 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> Cygwin does not do this on a standard installation.  Is it something you've done
> 
> I did use the standard Setup and nothing else...  My $HOME looks fine, too:
> 
> $ cd
> $ pwd
> /home/ANTON
> $ getfacl .
> # file: .
> # owner: ANTON
> # group: None
> user::rwx
> group::---
> other::---
> default:user::rwx
> default:group::r-x
> default:other::r-x

The "group" and "other" entries are surprising (to me), but maybe that's not 
important.  On my system I have:

$ cd

$ pwd
/home/kbrown

$ getfacl .
# file: .
# owner: kbrown
# group: None
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

> Whatever is on drive G: was mostly also created by Cygwin -- I was just simply moving stuff from
> $HOME to there using tar (IIRC)...  Initially, it was a clean and empty NTFS volume (brand new).
> So it was something like:
> 
> $ mkdir /cygdrive/g/cygwin

At this point the permissions on /cygdrive/g/cygwin are influenced by the ACL on 
/cygdrive/g.  What I would typically do in this situation is

   getfacl ~ | setfacl -f - /cygdrive/g/cygwin

That way I'm sure I won't have any surprises with permissions when working in 
/cygdrive/g/cygwin.  Do you want to try that and see if it makes a difference?

Ken

RE: Weird issue with file permissions

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

getfacl does not work even for the .socket "file" in my home directory for which ~/sun works perfectly fine with permissions
(and all subdirectories crated with mkdir under it).

Also like I said, ~/sun also works perfectly fine in /cygdrive/g/cygwin/ but not if I created a subdirectory with the shell's mkdir command.

> Can you give us more information about where that error is coming from?  Are you

These are the relevant parts from strace (I think):

for "getfacl .socket" while in my $HOME:

   62   25757 [main] getfacl 33904 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin64\home\ANTON\.socket)
   95   25852 [main] getfacl 33904 symlink_info::check: not a symlink
   31   25883 [main] getfacl 33904 symlink_info::check: 0 = symlink.check(C:\cygwin64\home\ANTON\.socket, 0xFFFFB860) (mount_flags 0x30008, path_flags 0x20)
   26   25909 [main] getfacl 33904 path_conv::check: this->path(C:\cygwin64\home\ANTON\.socket), has_acls(1)
   28   25937 [main] getfacl 33904 build_fh_pc: fh 0x18035FE50, dev 001E0078
   25   25962 [main] getfacl 33904 __set_errno: virtual __acl_t* fhandler_base::acl_get(acl_type_t):565 setting errno 134

for "getfacl .socket" while in /cygdrive/g/cygwin:

  114   29018 [main] getfacl 34007 symlink_info::check: 0x0 = NtCreateFile (\??\G:\cygwin\.socket)
  194   29212 [main] getfacl 34007 symlink_info::check: not a symlink
   30   29242 [main] getfacl 34007 symlink_info::check: 0 = symlink.check(G:\cygwin\.socket, 0xFFFFB8F0) (mount_flags 0x4020, path_flags 0x20)
   45   29287 [main] getfacl 34007 path_conv::check: this->path(G:\cygwin\.socket), has_acls(1)
   58   29345 [main] getfacl 34007 build_fh_pc: fh 0x18035FE40, dev 001E0078
   37   29382 [main] getfacl 34007 stat_worker: (\??\G:\cygwin\.socket, 0xFFFFCB60, 0x18035FE40), file_attributes 36
  212   29594 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
  202   29796 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
  205   30001 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
  145   30146 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
  175   30321 [main] getfacl 34007 fhandler_base::fstat_helper: 0 = fstat (\??\G:\cygwin\.socket, 0xFFFFCB60) st_size=54, st_mode=0140666, st_ino=1407374883583365st_atim=62BF3147.159B86B4 st_ctim=62BF3147.16341D34 st_mtim=62BF3147.16341D34 st_birthtim=62BF3147.159B86B4
   52   30373 [main] getfacl 34007 stat_worker: 0 = (\??\G:\cygwin\.socket,0xFFFFCB60)
   62   30435 [main] getfacl 34007 normalize_posix_path: src .socket
   27   30462 [main] getfacl 34007 cwdstuff::get: posix /cygdrive/g/cygwin
   33   30495 [main] getfacl 34007 cwdstuff::get: (/cygdrive/g/cygwin) = cwdstuff::get (0x800000010, 32768, 1, 0), errno 0
   32   30527 [main] getfacl 34007 normalize_posix_path: /cygdrive/g/cygwin/.socket = normalize_posix_path (.socket)
   25   30552 [main] getfacl 34007 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/g/cygwin/.socket)
   28   30580 [main] getfacl 34007 mount_info::cygdrive_win32_path: src '/cygdrive/g/cygwin/.socket', dst 'G:\cygwin\.socket'
   29   30609 [main] getfacl 34007 mount_info::conv_to_win32_path: src_path /cygdrive/g/cygwin/.socket, dst G:\cygwin\.socket, flags 0x4020, rc 0
   56   30665 [main] getfacl 34007 symlink_info::check: 0x0 = NtCreateFile (\??\G:\cygwin\.socket)
  128   30793 [main] getfacl 34007 symlink_info::check: not a symlink
   55   30848 [main] getfacl 34007 symlink_info::check: 0 = symlink.check(G:\cygwin\.socket, 0xFFFFB860) (mount_flags 0x4020, path_flags 0x20)
   35   30883 [main] getfacl 34007 path_conv::check: this->path(G:\cygwin\.socket), has_acls(1)
   43   30926 [main] getfacl 34007 build_fh_pc: fh 0x18035FE40, dev 001E0078
   36   30962 [main] getfacl 34007 __set_errno: virtual __acl_t* fhandler_base::acl_get(acl_type_t):565 setting errno 134

I see that it is trying to connect to cygserver and it's actually running on my machine.
If I stop it, ~/sun still can't create proper permissions in a cygwin-made subdirectory,
and getfacl shows a longer trace but the same "Not supported" outcome.

> And what can you tell us about the drive /cygdrive/g?

$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto)
G: on /cygdrive/g type ntfs (binary,posix=0,user,noumount,auto)
I: on /cygdrive/i type ntfs (binary,posix=0,user,noumount,auto)

But if I created a subdirectory in G:\cygwin from Windows (e.g. with cmd's mkdir), then sun.c would work!

$ cmd /c 'mkdir G:\cygwin\subdir-cmd'
$ cd /cygdrive/g/cygwin/subdir-cmd
$ ~/sun
fstat mode = 140666
stat mode = 140666
$ ls -l .socket
srw-rw-rw-+ 1 ANTON None 0 Jul  1 13:40 .socket=

$ icacls .
. BUILTIN\Administrators:(I)(F)
  BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
  NT AUTHORITY\Authenticated Users:(I)(M)
  NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
  BUILTIN\Users:(I)(RX)
  BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

$ icacls .socket
.socket NULL SID:(DENY)(Rc,S,WEA,X,DC)
        ANTON\ANTON:(R,W,D,WDAC,WO)
        ANTON\None:(DENY)(S,X)
        NT AUTHORITY\Authenticated Users:(DENY)(S,X)
        NT AUTHORITY\SYSTEM:(DENY)(S,X)
        BUILTIN\Administrators:(DENY)(S,X)
        BUILTIN\Users:(DENY)(S,X)
        ANTON\None:(RX,W)
        NT AUTHORITY\Authenticated Users:(RX,W)
        NT AUTHORITY\SYSTEM:(RX,W)
        BUILTIN\Administrators:(RX,W)
        BUILTIN\Users:(RX,W)
        Everyone:(R,W)

Lastly, I forgot to list all the involved directories as they look from under Cygwin with their permissions,
if that's of any help:

$ ls -ld ~ ~/.socket ~/subdir ~/subdir/.socket
drwx------+ 1 ANTON None 0 Jul  1 13:36 /home/ANTON/
srw-rw-rw-  1 ANTON None 0 Jul  1 13:36 /home/ANTON/.socket=
drwxr-xr-x+ 1 ANTON None 0 Jul  1 13:36 /home/ANTON/subdir/
srw-rw-rw-  1 ANTON None 0 Jul  1 13:36 /home/ANTON/subdir/.socket=

$ ls -ld /cygdrive/g/cygwin /cygdrive/g/cygwin/.socket /cygdrive/g/cygwin/subdir /cygdrive/g/cygwin/subdir/.socket /cygdrive/g/cygwin/subdir-cmd /cygdrive/g/cygwin/subdir-cmd/.socket
drwxrwx---+ 1 ANTON None 0 Jul  1 13:40 /cygdrive/g/cygwin/
srw-rw-rw-+ 1 ANTON None 0 Jul  1 13:39 /cygdrive/g/cygwin/.socket=
drwxrwxr-x+ 1 ANTON None 0 Jul  1 13:39 /cygdrive/g/cygwin/subdir/
srw-rw-r--+ 1 ANTON None 0 Jul  1 13:39 /cygdrive/g/cygwin/subdir/.socket=
drwxrwx---+ 1 ANTON None 0 Jul  1 13:40 /cygdrive/g/cygwin/subdir-cmd/
srw-rw-rw-+ 1 ANTON None 0 Jul  1 13:40 /cygdrive/g/cygwin/subdir-cmd/.socket=

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: Weird issue with file permissions

[Ken Brown]

On 7/1/2022 2:00 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> getfacl does not work even for the .socket "file" in my home directory for which ~/sun works perfectly fine with permissions
> (and all subdirectories crated with mkdir under it).
> 
> Also like I said, ~/sun also works perfectly fine in /cygdrive/g/cygwin/ but not if I created a subdirectory with the shell's mkdir command.
> 
>> Can you give us more information about where that error is coming from?  Are you
> 
> These are the relevant parts from strace (I think):
> 
> for "getfacl .socket" while in my $HOME:
> 
>     62   25757 [main] getfacl 33904 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin64\home\ANTON\.socket)
>     95   25852 [main] getfacl 33904 symlink_info::check: not a symlink
>     31   25883 [main] getfacl 33904 symlink_info::check: 0 = symlink.check(C:\cygwin64\home\ANTON\.socket, 0xFFFFB860) (mount_flags 0x30008, path_flags 0x20)
>     26   25909 [main] getfacl 33904 path_conv::check: this->path(C:\cygwin64\home\ANTON\.socket), has_acls(1)
>     28   25937 [main] getfacl 33904 build_fh_pc: fh 0x18035FE50, dev 001E0078
>     25   25962 [main] getfacl 33904 __set_errno: virtual __acl_t* fhandler_base::acl_get(acl_type_t):565 setting errno 134
> 
> for "getfacl .socket" while in /cygdrive/g/cygwin:
> 
>    114   29018 [main] getfacl 34007 symlink_info::check: 0x0 = NtCreateFile (\??\G:\cygwin\.socket)
>    194   29212 [main] getfacl 34007 symlink_info::check: not a symlink
>     30   29242 [main] getfacl 34007 symlink_info::check: 0 = symlink.check(G:\cygwin\.socket, 0xFFFFB8F0) (mount_flags 0x4020, path_flags 0x20)
>     45   29287 [main] getfacl 34007 path_conv::check: this->path(G:\cygwin\.socket), has_acls(1)
>     58   29345 [main] getfacl 34007 build_fh_pc: fh 0x18035FE40, dev 001E0078
>     37   29382 [main] getfacl 34007 stat_worker: (\??\G:\cygwin\.socket, 0xFFFFCB60, 0x18035FE40), file_attributes 36
>    212   29594 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
>    202   29796 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
>    205   30001 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
>    145   30146 [main] getfacl 34007 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
>    175   30321 [main] getfacl 34007 fhandler_base::fstat_helper: 0 = fstat (\??\G:\cygwin\.socket, 0xFFFFCB60) st_size=54, st_mode=0140666, st_ino=1407374883583365st_atim=62BF3147.159B86B4 st_ctim=62BF3147.16341D34 st_mtim=62BF3147.16341D34 st_birthtim=62BF3147.159B86B4
>     52   30373 [main] getfacl 34007 stat_worker: 0 = (\??\G:\cygwin\.socket,0xFFFFCB60)
>     62   30435 [main] getfacl 34007 normalize_posix_path: src .socket
>     27   30462 [main] getfacl 34007 cwdstuff::get: posix /cygdrive/g/cygwin
>     33   30495 [main] getfacl 34007 cwdstuff::get: (/cygdrive/g/cygwin) = cwdstuff::get (0x800000010, 32768, 1, 0), errno 0
>     32   30527 [main] getfacl 34007 normalize_posix_path: /cygdrive/g/cygwin/.socket = normalize_posix_path (.socket)
>     25   30552 [main] getfacl 34007 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/g/cygwin/.socket)
>     28   30580 [main] getfacl 34007 mount_info::cygdrive_win32_path: src '/cygdrive/g/cygwin/.socket', dst 'G:\cygwin\.socket'
>     29   30609 [main] getfacl 34007 mount_info::conv_to_win32_path: src_path /cygdrive/g/cygwin/.socket, dst G:\cygwin\.socket, flags 0x4020, rc 0
>     56   30665 [main] getfacl 34007 symlink_info::check: 0x0 = NtCreateFile (\??\G:\cygwin\.socket)
>    128   30793 [main] getfacl 34007 symlink_info::check: not a symlink
>     55   30848 [main] getfacl 34007 symlink_info::check: 0 = symlink.check(G:\cygwin\.socket, 0xFFFFB860) (mount_flags 0x4020, path_flags 0x20)
>     35   30883 [main] getfacl 34007 path_conv::check: this->path(G:\cygwin\.socket), has_acls(1)
>     43   30926 [main] getfacl 34007 build_fh_pc: fh 0x18035FE40, dev 001E0078
>     36   30962 [main] getfacl 34007 __set_errno: virtual __acl_t* fhandler_base::acl_get(acl_type_t):565 setting errno 134

Thanks.  The problem is that fhandler_base::acl_get *always* returns ENOTSUP.  I 
think we need a method fhandler_socket_local::acl_get that calls 
fhandler_disk_file::acl_get on the underlying socket file when it should. 
(There's already a similar method, fhandler_socket_local::facl.)  I'll submit a 
patch to do that, and then getfacl should work on socket files.  I'm not sure 
what further work will be needed to deal with the problems you reported, but 
that's a first step.

Ken

Re: Weird issue with file permissions

[Ken Brown]

On 7/1/2022 2:00 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Lastly, I forgot to list all the involved directories as they look from under Cygwin with their permissions,
> if that's of any help:
> 
> $ ls -ld ~ ~/.socket ~/subdir ~/subdir/.socket
> drwx------+ 1 ANTON None 0 Jul  1 13:36 /home/ANTON/
> srw-rw-rw-  1 ANTON None 0 Jul  1 13:36 /home/ANTON/.socket=
> drwxr-xr-x+ 1 ANTON None 0 Jul  1 13:36 /home/ANTON/subdir/
> srw-rw-rw-  1 ANTON None 0 Jul  1 13:36 /home/ANTON/subdir/.socket=
> 
> $ ls -ld /cygdrive/g/cygwin /cygdrive/g/cygwin/.socket /cygdrive/g/cygwin/subdir /cygdrive/g/cygwin/subdir/.socket /cygdrive/g/cygwin/subdir-cmd /cygdrive/g/cygwin/subdir-cmd/.socket
> drwxrwx---+ 1 ANTON None 0 Jul  1 13:40 /cygdrive/g/cygwin/
> srw-rw-rw-+ 1 ANTON None 0 Jul  1 13:39 /cygdrive/g/cygwin/.socket=
> drwxrwxr-x+ 1 ANTON None 0 Jul  1 13:39 /cygdrive/g/cygwin/subdir/
> srw-rw-r--+ 1 ANTON None 0 Jul  1 13:39 /cygdrive/g/cygwin/subdir/.socket=
> drwxrwx---+ 1 ANTON None 0 Jul  1 13:40 /cygdrive/g/cygwin/subdir-cmd/
> srw-rw-rw-+ 1 ANTON None 0 Jul  1 13:40 /cygdrive/g/cygwin/subdir-cmd/.socket=

I've got my patch ready but need to test it before submitting it.  In the 
meantime, I just noticed that all of the directories you've listed have 
non-standard ACL entries (indicated by the + signs).  getfacl should show you 
what they are.

Cygwin does not do this on a standard installation.  Is it something you've done 
intentionally?  If not, you might want to remove those non-standard entries and 
see if that has any impact on the problems you've reported.  The -b and -k 
options to setfacl are useful here.

Ken

Weird issue with file permissions

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

Hi all,

I am having an issue with socket file permissions...

So here's a mockup of code that shows the problem:

$ cat sun.c
#include <stdio.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/un.h>


#define SOCKET "./.socket"

int main()
{
    struct sockaddr_un addr;
    struct stat st;
    mode_t u;
    int s;

    /* create a UNIX socket */
    if ((s = socket(PF_UNIX, SOCK_STREAM, 0)) < 0) {
        perror("socket");
        return 1;
    }

    memset(&addr, 0, sizeof(addr));
    addr.sun_family = PF_UNIX;
    strcpy(addr.sun_path, SOCKET);
    unlink(SOCKET);

    u = umask(0);
    if (bind(s, (struct sockaddr*) &addr, sizeof(addr)) != 0) {
        perror("bind");
        return 1;
    }

    umask(u);
    if (fchmod(s, 0666) < 0)
        printf("fchmod: %m\n");

    if (fstat(s, &st) < 0) {
        perror("fstat");
        return 1;
    }

    printf("fstat mode = %03o\n", st.st_mode);


    if (stat(SOCKET, &st) < 0) {
        perror("stat");
        return 1;
    }

    printf("stat mode = %03o\n", st.st_mode);

    return 0;
}

$ gcc -Wall -o sun sun.c

Now, if I run this code in my Cygwin home directory (and any directory that I create using "mkdir..." under it),
I am getting the expected results:

$ ~/sun
fstat mode = 140666
stat mode = 140666

$ ls -l .socket
srw-rw-rw-+ 1 ANTON None 0 Jul  1 01:19 .socket=

However, if I run it elsewhere (different drive "cd /cygdrive/g/cygwin" -- it's NOT where Cygwin is installed,
just a folder that keeps files for Cygwin development, the installation is on C:\Cygwin64), I cannot predict
the results.  What's weird is that fstat and stat report different file modes.

$ pwd
/cygdrive/g/cygwin
$ ~/sun
fstat mode = 140666
stat mode = 140666
$ ls -l .socket
srw-rw-rw-+ 1 ANTON None 0 Jul  1 01:24 .socket=

So all's good here, BUT:

$ mkdir subdir
$ cd subdir
$ pwd
/cygdrive/g/cygwin/subdir
$ ~/sun
fstat mode = 140666
stat mode = 140664
$ ls -l .socket
srw-rw-r--+ 1 ANTON None 0 Jul  1 01:25 .socket=

Note that fstat lied!

For some reason getfacl returns "Not supported", so I could not investigate with that, but I'm showing below
the icacls outputs for both /cygwin/g/cygwin and /cygdrive/g/cygwin/subdir with their .socket files, respectively.

At any rate, it looks like fstat, despite reporting the mode, wasn't actually able to bake it on disk
using those insanely complicated Windows permissions.

What's more insane, is that using the chmod command from shell, I'm able to change the permissions to 0666,
and it sticks:

$ pwd 
/cygdrive/g/cygwin/subdir
$ chmod 0666 .socket
$ ls -l .socket
srw-rw-rw-+ 1 ANTON None 0 Jul  1 01:25 .socket=

Any insights will be highly appreciated!
Thanks.

$ pwd
/cygdrive/g/cygwin

$ icacls .
. BUILTIN\Administrators:(I)(F)
  BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
  NT AUTHORITY\Authenticated Users:(I)(M)
  NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
  BUILTIN\Users:(I)(RX)
  BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

$ icacls .socket
.socket NULL SID:(DENY)(Rc,S,WEA,X,DC)
        ANTON\ANTON:(R,W,D,WDAC,WO)
        ANTON\None:(DENY)(S,X)
        NT AUTHORITY\Authenticated Users:(DENY)(S,X)
        NT AUTHORITY\SYSTEM:(DENY)(S,X)
        BUILTIN\Administrators:(DENY)(S,X)
        BUILTIN\Users:(DENY)(S,X)
        ANTON\None:(RX,W)
        NT AUTHORITY\Authenticated Users:(RX,W)
        NT AUTHORITY\SYSTEM:(RX,W)
        BUILTIN\Administrators:(RX,W)
        BUILTIN\Users:(RX,W)
        Everyone:(R,W)

$ cd subdir

$ icacls .
. NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
  ANTON\ANTON:(F)
  ANTON\None:(RX)
  NT AUTHORITY\Authenticated Users:(RX,W,DC)
  NT AUTHORITY\SYSTEM:(RX,W,DC)
  BUILTIN\Administrators:(RX,W,DC)
  BUILTIN\Users:(RX)
  Everyone:(RX)
  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  CREATOR GROUP:(OI)(CI)(IO)(RX)
  NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(RX,W,DC)
  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
  BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
  BUILTIN\Users:(OI)(CI)(IO)(RX)
  Everyone:(OI)(CI)(IO)(RX)

As created by the program:

$ icacls .socket
.socket NULL SID:(DENY)(Rc,S,WEA,X,DC)
        ANTON\ANTON:(R,W,D,WDAC,WO)
        ANTON\None:(DENY)(S,X)
        NT AUTHORITY\Authenticated Users:(DENY)(S,X)
        NT AUTHORITY\SYSTEM:(DENY)(S,X)
        BUILTIN\Administrators:(DENY)(S,X)
        BUILTIN\Users:(DENY)(S,X)
        ANTON\None:(RX)
        NT AUTHORITY\Authenticated Users:(RX,W)
        NT AUTHORITY\SYSTEM:(RX,W)
        BUILTIN\Administrators:(RX,W)
        BUILTIN\Users:(RX)
        Everyone:(R)

After chmod:

$ icacls .socket
.socket NULL SID:(DENY)(Rc,S,WEA,X,DC)
        ANTON\ANTON:(R,W,D,WDAC,WO)
        ANTON\None:(DENY)(S,X)
        NT AUTHORITY\Authenticated Users:(DENY)(S,X)
        NT AUTHORITY\SYSTEM:(DENY)(S,X)
        BUILTIN\Administrators:(DENY)(S,X)
        BUILTIN\Users:(DENY)(S,X)
        ANTON\None:(RX)
        NT AUTHORITY\Authenticated Users:(RX,W)
        NT AUTHORITY\SYSTEM:(RX,W)
        BUILTIN\Administrators:(RX,W)
        BUILTIN\Users:(RX)
        ANTON\None:(DENY)(W,DC)
        BUILTIN\Users:(DENY)(W,DC)
        Everyone:(R,W)

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: Weird issue with file permissions

[Ken Brown]

On 7/1/2022 1:46 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Now, if I run this code in my Cygwin home directory (and any directory that I create using "mkdir..." under it),
> I am getting the expected results:
> 
> $ ~/sun
> fstat mode = 140666
> stat mode = 140666
> 
> $ ls -l .socket
> srw-rw-rw-+ 1 ANTON None 0 Jul  1 01:19 .socket=
> 
> However, if I run it elsewhere (different drive "cd /cygdrive/g/cygwin" -- it's NOT where Cygwin is installed,
> just a folder that keeps files for Cygwin development, the installation is on C:\Cygwin64), I cannot predict
> the results.  What's weird is that fstat and stat report different file modes.
> 
> $ pwd
> /cygdrive/g/cygwin
> $ ~/sun
> fstat mode = 140666
> stat mode = 140666
> $ ls -l .socket
> srw-rw-rw-+ 1 ANTON None 0 Jul  1 01:24 .socket=
> 
> So all's good here, BUT:
> 
> $ mkdir subdir
> $ cd subdir
> $ pwd
> /cygdrive/g/cygwin/subdir
> $ ~/sun
> fstat mode = 140666
> stat mode = 140664
> $ ls -l .socket
> srw-rw-r--+ 1 ANTON None 0 Jul  1 01:25 .socket=
> 
> Note that fstat lied!
> 
> For some reason getfacl returns "Not supported", so I could not investigate with that

Can you give us more information about where that error is coming from?  Are you 
able to run getfacl under gdb and show us a backtrace from that point?  I often 
find it helpful to first run the program under strace in order to locate the 
source of the error, so I know where to set a breakpoint in gdb.

And what can you tell us about the drive /cygdrive/g?  The failure of getfacl 
suggests that Cygwin thinks the drive doesn't support ACLs, in which case it 
might just be faking permissions (lying).

Ken