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

Question

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