DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; q=dns; s=default; b=FOC8s
	fi+dhWhct9NIIp89Tl/OWCCrM0aZOCT/47FYIHYbbuT3slvs+U9tkxzo1NxGi/xX
	GvYUy4mMjDd8QkBmECHCr8jKWACB0Ja9RKQ1tKjuFm4mtYpXugf2n3GK22AK4qh+
	JzBpAfbSyfozYpA4ksICc+RlfJrqmBIDqpGux8=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin@cygwin.com
Subject: Re: [TESTERS needed] New POSIX permission handling
References: <20150410100703.GA4401@calimero.vinschen.de>	<87lhhzcarc.fsf@Rainer.invalid> <5528E2ED.7090105@gmail.com>	<87d23bc9r5.fsf@Rainer.invalid> <5528EE66.8070305@gmail.com>
Date: Sat, 11 Apr 2015 13:51:09 +0200
In-Reply-To: <5528EE66.8070305@gmail.com> (David Macek's message of "Sat, 11	Apr 2015 11:50:30 +0200")
Message-ID: <878udydgsy.fsf@Rainer.invalid>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

David Macek writes:
> https://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx
> says otherwise about the group-in-group rights.

As I see it, nesting groups is just a more efficient way of populating
them, so by expanding the nested groups recursively you'll end up with
the effective set of users that have those rights.  But if I have a DACL
permission for "Domain Admins" that still doesn't mean that
"Administrators" (the group) gets access.  The other way around
(intentionally) works, by virtue of "Domain Admins" being a member of
"Administrators".  Also, "Administrator" (the account) is by default a
member of both "Administrators" and "Domain Administrators", which is a
bit confusing.

> The way I see it, the point of the code change was to prevent the
> "implicit" Administrators and SYSTEM DACL entries from showing up in
> the computed POSIX access mask because they nicely match the implicit
> rights root accounts have on POSIX systems and because they're
> unhelpful and sometimes problematic.

My point is that the interpretation of who gets to call himself "root"
in that analogy is quite fuzzy and sometimes depends on the filesystem
you look at.  The choice proffered by Cygwin now is mostly correct for
local file systems, but not necessarily for network shares (and most
certainly not for a few important ones I'll have to deal with).

The fallback will be to mount with "noacl" as before, something I had
hoped would no longer be necessary.  I have a few applications where the
faked file modes simply don't cut it and so far I've been lucky that
either the shares these need to be on are configured differently by
default (like my home "drive") or I could convince IT to give me
something non-standard.  But the next round of filer or server upgrades
or changed security policies might leave me stranded, so I'm really not
too keen to rely on that indefinitely.

> As neither Domain Administrators nor Power Users have this combination
> of properties (presence on most filesystem objects by default and
> SeTakeOwnershipPrivilege), I think it's useful to have them appear in
> the mask.

For isolated systems and small networks, this is wholly sufficient.
Large networked installations have, for better or worse, more
complicated setups.  Again, I see a lot of cruft that likely wouldn't be
necessary and is probably largely historical, but some of it really
can't be changed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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