This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mar 30 23:26, Eliot Moss wrote: > Dear Cygwin community -- > > Along with some others, I've been struggling a little to accommodate > the changes to permissions handling that came lately. I think I about > have it figured out to work mostly Unix-like within my cygwin tree, > but have one remaining thing I am wondering about, even though I have > been through the ntsec document more than once. (I think everyone > will admit that this is complicated :-) ...) > > - I have created a new group, that I call Cygwin, to be the typical > group of cygwin-related files, so that I can control group permissions > appropriately. I am a member of that group. > > - I have found that if a directory is chmod to 2755 (2000 == set gid) > and the directory's group is Cygwin, then cygwin-created files in > the directory get group Cygwin. (This was not necessarily happening > before.) To get this to happen, I had to list the sid of the Cygwin > group as my group in my line of the /etc/passwd file. Otherwise the > group would be me, which does not seem to allow the same differentiation > of user versus group permissions. The group s-bit is not yet taken into account. If you have "Cygwin" as your primary group in /etc/passwd or the account DB of choice (SAM/AD), using 0755 as permissions should do the same thing. Taking the group s-bit into account is part of my work-in-progress for Cygwin 1.7.36. > - I could not find an explanation of the 'mask' list by getfacl. Near > as I can tell it is not really settable, although setfacl does not > complain, and it is the OR of the permissions of the various groups. I explained that in the release annnouncement, I think. The mask value is required per POSIX, but it's faked on Cygwin yet, the reason being that Windows doesn't know such a mask value. I have an idea how to make this work, but I need time for that. The last two or three weeks I had more than enough other stuff so I couldn't concentrate on this, and it looks like this week is the same. > Now, to what I would like to do. Ideally I want SYSTEM to have rwx > access to everything. Seems a generally good idea on Windows, and at > least r permission on files and rx on directories is needed for my > backup program to access things. > > But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls > always lists rwx for the group part of any such file, and chmod, if > applied, affects SYSTEM's access bits. What I'd like is for SYSTEM's > role here to be hidden. If there are any files where I want to restrict > SYSTEM, I can use Windows tools or setfacl to manipulate them. > > Is this simply not possible with the new scheme? No. We discussed this at one point a few weeks ago, but it still seems wrong to me to hide the permissions of any account. Where does it end? Is it only SYSTEM, or Administrators as well? And then Domain Admins? Backup Operators? This contradicts the entire POSIX permission model. I'm *very* reluctant to ignore accounts in permission handling. Why does SYSTEM need full access to the files? If it's a backup tool, it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway. Every tool with Administrators in the token has the right to enable these access rights anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpK7bt05MZNI.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |