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]

Re: More about permissions


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]