4

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

  • 1
    (1) Please specify the groups that are at play.   It doesn’t have to be the real names you use, just like (I assume) you are using User.Name as a placeholder for your actual username.  (2) Please specify more exactly what permission-relevant results you are getting.  Specifically, are the files owned by the group of the User.Name account?  What modes are you getting?  I’m guessing 640 and 660, but I can’t tell for sure from your question.  (3) What happens (permissions-wise) when you create files by other means; e.g., echo foo > or echo foo | dd of=? – G-Man Says 'Reinstate Monica' Aug 11 '23 at 03:39
  • I added examples to the question. Thanks for the prompting. Let me know if further details would help. – user2153235 Aug 11 '23 at 05:28
  • 1
    Thanks for adding the detail.  (And I guess I should admit that I may have misread the first version of the question.  I was confused by your reference to “cross-account”; I thought you were saying the system was treating Admin and User.Name differently.  In fact, the question is about getting 600 mode when creating a file in the Unix directory tree versus getting 660 in the Windows directory tree.) … So, anyway, the problem isn’t specific to the zip command. … (Cont’d) – G-Man Says 'Reinstate Monica' Aug 12 '23 at 06:34
  • 1
    (Cont’d) …  The + at the end of the mode for the /c/Users files tells me that ACLs are at work.  I’m not sure I’ll be able to answer the question, but here are some suggestions to you: run getfacl ~/tmp for both users, run getfacl /c/Users/Public/tmp, and look at the permissions of C:\Users\Public\tmp in Windows, and see if you can figure it out from that.  If you’re still stuck, add the output of those commands to your question.  Also, in general (when dealing with permissions problems), I advise you to use ls -la and look at what it says for .. – G-Man Says 'Reinstate Monica' Aug 12 '23 at 06:34
  • Thanks for that. It sent me on a many-hour reading expedition of file permissions and getfacl and added the results to the question. I did inspect the Windows permissions for the folders containing the newly created files, but the Windows permissions seem more complicated. I recall this being a complication in past Cygwin mailing list threads. I was really hoping that reverse engineering the possible operational processes from the details upward wouldn't be the way to go, and that there would be a high level document explaining it from the top down. – user2153235 Aug 13 '23 at 07:25
  • 1
    A bit more: (4) Every file has a UID and a GID (which may sometimes be called “owner” and ”owning group”).  They are the values displayed by ls -l and stat.  They are normally initially set to the UID and GID of the process that creates the file, although there may be exceptions to that.  Recall that a user can belong to multiple groups, and a user’s process will have a primary GID that is (usually) one of those groups.  (See the id command.)  The UID and GID of a file can be changed by the chown and chgrp commands — but that isn’t relevant to your question.  … (Cont’d) – G-Man Says 'Reinstate Monica' Aug 14 '23 at 05:42
  • 1
    (Cont’d) …  (5) I don’t believe that “None” is a special keyword indicating that there is no group.  If you run getent group, you may see that “None” is simply the name of a group inherited from Windows, like “SYSTEM”, “INTERACTIVE” and “Administrators”.  Cygwin seems to like to use the “None” group; I don’t know why.  (6) group::… refers to the current GID of the file (or directory).  So, for the files (and directories) in /home, group::… refers to “None”.  But, for /c/Users/Public/Documents, it refers to “SYSTEM”, because that’s the GID of that directory. … (Cont’d) – G-Man Says 'Reinstate Monica' Aug 14 '23 at 05:42
  • 1
    (Cont’d) …  (7) You ask why you aren’t getting execute permission.  See facl ignoring the "x" permission but only on files. – G-Man Says 'Reinstate Monica' Aug 14 '23 at 05:42
  • Thank you for the additional pointers, G-Man, including the investigative commands to try and the reason why the x bit isn't enabled for files. The id command does indeed show that primary group is None for User.Name and Admin. Issuing getent group yields None as the first record, but unfortunately, I haven't found anything about this group online. – user2153235 Aug 14 '23 at 07:09
  • Like this Q&A, None also shows up for in the Windows file properties, but lusrmgr.msc shows no such group, even when run from the Admin account. I can find no tabulation of a None group here, here, or here. – user2153235 Aug 14 '23 at 07:10
  • What is the issue in putting the files under /home/ folder so that you do not need to puzzle between Cygwin/Unix permission and Windows ACL ones ? /c/Users/ is better to be left to pure Windows matter – matzeri Nov 25 '23 at 06:47

0 Answers0