X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=eDqLh+jx19xlWFJY
	yTuYSiunc5TDGX69S09YD5QD5+z3EjY0Tg9zK2FkpRDyK3vmr53DwUwjFAysl3nI
	M+8wmu6FQSCnNtAKOS84hEc87k8visMeyYVsjd32z06JVtvgWbTs+9eluUOC9svA
	DpUDp67G8wSe/6Pz/Wruccgu0m4=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=H8DZ91fi/t8tsMHX5U/ErF
	H1eeY=; b=Q67P21uICJWkncTF6eroedRE6GMf2phvjvBL/p3jXQpYq8vFVnf5xM
	Q49V3SM8A+R5vE73MTHPHcmsKKyHzIf2cPSol95v+4w4F0uohq2Td9NrqPhr00Cz
	ubq7Ck46mzY8KdubD7fFNa9U4xTuXG3V7unaKVDEYvxVC2I4fkns8=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	csmail.cs.umass.edu
Message-ID:	<551A9149.4020408@cs.umass.edu>
Date:	Tue, 31 Mar 2015 08:21:29 -0400
From:	Eliot Moss <moss AT cs DOT umass DOT edu>
Reply-To:	moss AT cs DOT umass DOT edu
User-Agent:	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: More about permissions
References:	<551A13D8 DOT 1030701 AT cs DOT umass DOT edu> <20150331101534 DOT GE32403 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20150331101534.GE32403@calimero.vinschen.de>
X-IsSubscribed:	yes

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

- Raw text -