Cygwin inheritance of Windows's security for cross-account file creation/modificaton?

On a Windows 10 laptop, I have an administrator account Admin, a non-administrator account User.Name, and the default Public account. From either Admin or User.Name accounts, files created in the ~/ tree have read/write permission for the *user* but not the *group*. The command ls -l shows the group to be None. In the following examples, the commands were issued in a different order than shown here, so the time stamps aren't very informative. Example from ~/tmp of User.Name account: User.Name@Laptop-Hostname ~/tmp $ echo "Hello" > Test.txt User.Name@Laptop-Hostname ~/tmp $ zip Test.zip Test.txt adding: Test.txt (stored 0%) User.Name@Laptop-Hostname ~/tmp $ ls -l Test.{txt,zip} -rw------- 1 User.Name None 6 2023-08-11 00:42 Test.txt -rw------- 1 User.Name None 172 2023-08-11 01:05 Test.zip Example from ~/tmp of Admin account: Admin@Laptop-Hostname ~/tmp $ echo "Hello" > Test.txt Admin@Laptop-Hostname ~/tmp $ zip Test.zip Test.txt adding: Test.txt (stored 0%) Admin@Laptop-Hostname ~/tmp $ ls -l Test.{txt,zip} -rw------- 1 Admin None 6 2023-08-11 00:44 Test.txt -rw------- 1 Admin None 172 2023-08-11 01:02 Test.zip From account User.Name or Admin, however, if I create files in the /c/Users/Public/ tree, both the user *and* the group have read/write permission. Example from ~/tmp of the User.Name account: User.Name@Laptop-Hostname ~/tmp $echo "Hello" > /c/Users/Public/tmp/TestFromUser.Name.txt User.Name@Laptop-Hostname ~/tmp $zip /c/Users/Public/tmp/TestFromUser.Name.zip Test.txt adding: Test.txt (stored 0%) User.Name@Laptop-Hostname ~/tmp $ls -l /c/Users/Public/tmp/TestFromUser.Name.{txt,zip} -rw-rw----+ 1 User.Name None 6 2023-08-11 00:52 /c/Users/Public/tmp/TestFromUser.Name.txt -rw-rw----+ 1 User.Name None 172 2023-08-11 00:53 /c/Users/Public/tmp/TestFromUser.Name.zip Example from ~/tmp of the Admin account: Admin@Laptop-Hostname ~/tmp $ echo "Hello" > /c/Users/Public/tmp/TestFromAdmin.txt Admin@Laptop-Hostname ~/tmp $ zip /c/Users/Public/tmp/TestFromAdmin.zip Test.txt adding: Test.txt (stored 0%) Admin@Laptop-Hostname ~/tmp $ ls -l /c/Users/Public/tmp/TestFromAdmin.{txt,zip} -rw-rw----+ 1 Admin None 6 2023-08-11 00:47 /c/Users/Public/tmp/TestFromAdmin.txt -rw-rw----+ 1 Admin None 172 2023-08-11 00:47 /c/Users/Public/tmp/TestFromAdmin.zip I confirmed the more open permissions by creating a zip file /c/Users/Public/tmp/Test.zip from the User.Name account. I can subsequently use Cygwin's zip command to add files to /c/Users/Public/tmp/Test.zip from the Admin account. Furthermore, I can subsequently use Cygwin's zip command add files to /c/Users/Public/tmp/Test.zip from the User.Name account. This is the behaviour that I find most convenient, but since I'm not using Windows Explorer, I wonder ***how Cygwin knows to make files in the /c/User/Public file tree readable and writable by both the user and the group?*** Where in the documentation should I focus on to understand this? I looked through the documentation on [POSIX accounts, permission, and security](https://www.cygwin.com/cygwin-ug-net/ntsec.html) , but frankly much of it delves into a lot of detail that I don't have the grounding to understand. I was wondering whether there might be a simpler high-level description of behaviour, such as "Cygwin interacts with Windows at such-and-such a level to inherit the security behaviour for cross-account creation and modification of files". A concise expression of the designed-for behaviour would help users understand what to expect under different cross-account operations. # Troubleshooting To keep the troubleshooting manageable, I note that the difference seems to be bewteen files written in a user's own file space versus Public's file space. Therefore, I compare User.Name writing to User.Name's file space versus User.Name writing to Public's file space, i.e., I dispense with the comparison with Admin. Based on *G-Man's* suggestions, I tested whether the different permissions were due to writing files in the Cygwin file tree rooted at /home rather than the larger Windows file tree rooted at /c/Users. It appears to be unrelated, which confirms that the different permissions are due to writing across to the Public account rather than writing to the /c/Users tree vs. the /home tree. User.Name@Laptop-Hostname ~/tmp $ # Permissions of one's Cygwin home directory. $ # Not sure how relevant this is. $ ls -ld ~ drwxr-xr-x 1 User.Name None 0 Aug 12 13:13 /home/User.Name User.Name@Laptop-Hostname ~/tmp $ # Permissions of one's own current directory. $ # Not sure how relevant this is. $ ls -ld ~/tmp drwx------ 1 User.Name None 0 Aug 12 02:20 /home/User.Name/tmp User.Name@Laptop-Hostname ~/tmp $ # Permissions of file created in one's own Windows file tree. $ # Only "User" has read/write access. $ ls > /c/Users/User.Name/Documents/List.txt $ ls -l /c/Users/User.Name/Documents/List.txt -rw-------+ 1 User.Name None 414 2023-08-12 13:19 /c/Users/User.Name/Documents/List.txt User.Name@Laptop-Hostname ~/tmp $ # Permissions of file created in Public's Windows file tree $ # Both "User" and "Group" have read/write access. $ ls > /c/Users/Public/Documents/List.txt $ ls -l /c/Users/Public/Documents/List.txt -rw-rw----+ 1 User.Name None 414 2023-08-12 13:20 /c/Users/Public/Documents/List.txt I was also advised to apply getfacl to the folders containing the files being compared. Here are the results of getfacl for a user's Cygwin "tmp" folder, a user's Windows "Documents" folder, and Public's "Documents" folder: User.Name@Laptop-Hostname ~/tmp $ # FACL for user's Cygwin "tmp" folder $ getfacl ~/tmp # file: /home/User.Name/tmp # owner: User.Name # group: None user::rwx group::--- other::--- default:user::rwx default:group::r-x default:other::r-x User.Name@Laptop-Hostname ~/tmp $ # FACL for user's Windows "Documents" folder $ getfacl /c/Users/User.Name/Documents/ # file: /c/Users/User.Name/Documents/ # owner: User.Name # group: None user::rwx group::--- group:SYSTEM:rwx #effective:--- group:Administrators:rwx #effective:--- mask::--- other::--- default:user::rwx default:group::--- default:group:SYSTEM:rwx #effective:--- default:group:Administrators:rwx #effective:--- default:mask::--- default:other::--- User.Name@Laptop-Hostname ~/tmp $ # FACL for Public's Windows "Documents" folder $ getfacl /c/Users/Public/Documents/ # file: /c/Users/Public/Documents/ # owner: SYSTEM # group: SYSTEM user::rwx group::--- group:BATCH:rwx group:INTERACTIVE:rwx group:SERVICE:rwx group:Administrators:rwx mask::rwx other::--- default:user::rwx default:user:SYSTEM:rwx default:group::--- default:group:BATCH:rwx default:group:INTERACTIVE:rwx default:group:SERVICE:rwx default:group:Administrators:rwx default:mask::rwx default:other::--- I read up about FACLs [here](https://web.archive.org/web/20121022035645/http://vanemery.com/Linux/ACL/POSIX_ACL_on_Linux.html) . I note that "named users" and "named groups" *both* belong to the "group class". The *effective* permissions are the minimum (bit-wise ANDing) of the named user/group permission bits with a 3-bit "mask". This corroborates with the presence of #effective:--- above. According to the text, the group permissions from ls -l are those of the *mask*, which may be more or less permissive than any specific named user/group. Counterintuitively, the *owning* group's permissions are *not* ANDed with the mask (if I understood the text correctly). I make two assumptions in interpreting the text: (1) that the "owning" group is the group to which the owner user belongs and (2) the group None corresponds to the FACL entries leading with group::. The first getfacl above is for /home/User.Name/tmp. The default entries explain why newly created files have user read/write permissions, but *not* why new files lack execute permission (x). Furthermore, the default entries are inconsistent with the fact that new files lack group/other read and execute permissions. The next getfacl is for /c/Users/User.Name/Documents/. The default --- entries *do* explain why group/other have no permissions for newly created files. The third and final getfacl is for /c/Users/Public/Documents/. The default:user::rwx entry does explain why a user such as User.Name has read/write access to a file created by User.Name -- *assuming that user refers to the owner/creator of the file rather than the directory.* The default:group:Administrators:rwx entry also explains why the Admin account could add to a Zip file created by User.Name. A confirmation of the correctness of this reasoning would be appreciated (and would constitute an answer, if one wishes to post it as the answer).