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).
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 theUser.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 >
orecho foo | dd of=
? – G-Man Says 'Reinstate Monica' Aug 11 '23 at 03:39Admin
andUser.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 thezip
command. … (Cont’d) – G-Man Says 'Reinstate Monica' Aug 12 '23 at 06:34+
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: rungetfacl ~/tmp
for both users, rungetfacl /c/Users/Public/tmp
, and look at the permissions ofC:\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 usels -la
and look at what it says for.
. – G-Man Says 'Reinstate Monica' Aug 12 '23 at 06:34getfacl
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:25ls -l
andstat
. 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 theid
command.) The UID and GID of a file can be changed by thechown
andchgrp
commands — but that isn’t relevant to your question. … (Cont’d) – G-Man Says 'Reinstate Monica' Aug 14 '23 at 05:42None
” is a special keyword indicating that there is no group. If you rungetent 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:42x
bit isn't enabled for files. Theid
command does indeed show that primary group isNone
forUser.Name
andAdmin
. Issuinggetent group
yieldsNone
as the first record, but unfortunately, I haven't found anything about this group online. – user2153235 Aug 14 '23 at 07:09None
also shows up for in the Windows file properties, butlusrmgr.msc
shows no such group, even when run from theAdmin
account. I can find no tabulation of aNone
group here, here, or here. – user2153235 Aug 14 '23 at 07:10/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