RE: Weird issue with file permissions
> 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 -- 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
Re: [EXTERNAL] Re: Weird issue with file permissions
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
Re: [EXTERNAL] Re: Weird issue with file permissions
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=2=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
RE: [EXTERNAL] Re: Weird issue with file permissions
> 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 -- 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
Re: Weird issue with file permissions
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 -- 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
RE: Weird issue with file permissions
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 -- 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
Re: Weird issue with file permissions
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 -- 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
RE: Weird issue with file permissions
> 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 -- 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
Re: Weird issue with file permissions
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 -- 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
RE: Weird issue with file permissions
> 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::--- -- 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
Re: Weird issue with file permissions
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 -- 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
Re: Weird issue with file permissions
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, 0xB860) (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, 0xB8F0) (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, 0xCB60, 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, 0xCB60) 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,0xCB60) 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 (0x80010, 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, 0xB860) (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 -- 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
RE: Weird issue with file permissions
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, 0xB860) (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, 0xB8F0) (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, 0xCB60, 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, 0xCB60) 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,0xCB60) 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 (0x80010, 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, 0xB860) (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!
Re: Weird issue with file permissions
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 -- 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
