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 3/31/2015 6:15 AM, Corinna Vinschen wrote:
On Mar 30 23:26, Eliot Moss wrote:

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.

Ok -- since I was using this mostly to try to get the primary group
inserted (instead of my user ("Eliot") as a group), this is fine for
most of my purposes.  I can see that eventually it would be nice to
get the POSIX behavior.

Taking the group s-bit into account is part of my work-in-progress for
Cygwin 1.7.36.

Step by step!

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

My disconnect was that I forgot this was a POSIX thing, perhaps because
none of the cygwin man pages really mentioned it.  On a POSIX system,
'man acl' explains it (I found the description of the computations of
access rights particularly clarifying).  Maybe the POSIX documentation
can be included somewhere, or a reference to it so that someone else
is not confused on this point?  I would agree that such documentation
refinement is not a high priority.

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.

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.

I can see that it might be a slippery slope.

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.

I am not sure this particular program (CrashPlan) works that way.

I suppose that I am seeing SYSTEM as the moral equivalent of root in
POSIX.  In POSIX, root can access anything, and I don't believes ACLs
can lock it out.  I agree that Windows does not really have the concept
of a single 'root'.  Administrators is close, but the various aspects
of root are split up in different ways.  We're not going to get a
perfect mapping.

Maybe what I am looking for is something like this:

- Certain Windows accounts/groups would be treated as 'root' for cygwin's
  purposes, perhaps controlled by a list in a file read when cygwin starts up.

- The permissions associated with root sids would be ignored by ls, chmod,
  and such, though (we could decide) perhaps visible and settable via getfacl
  and setfacl.  (Making them visible would not be very POSIX like, but it
  might be convenient.)  Getting fancier, we could have a flag control whether
  these permissions are visible through the get/setfacl interface.

- The umask and mask would not turn off permissions associated with these
  sids.

- If the current user/group privileges allow access because they are a root
  sid and the Windows ACL grants the permission, then the permission would
  be granted (i.e., the user is effectively root in that case).

In all this I am just thinking out loud.  There is no 'perfect' way to map
between the POSIX concepts and the Windows ones.  I am just not sure we've
taken the POSIX concept of 'root' and mapped it at all, though ...

The ntsec page does a great job of describing the complexities of mapping
identities and file permissions, and of switching identities.  It does not
really address the notion of which identities are like root.  I agree that
doing this thoroughly may impact set(e)uid.  Some programs would probably
like it if running under any 'root' sid (according to my concept above)
gave an effective uid of 0.  I am not sure that could work (the real sid
might need to be saved / available as well -- sigh).

Anyway, thanks for listening ...

Regards, and thank you for your continuing work on this!    Eliot

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]