public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin@cygwin.com
Subject: Re: [TESTERS needed] New POSIX permission handling
Date: Sat, 11 Apr 2015 11:51:00 -0000	[thread overview]
Message-ID: <878udydgsy.fsf@Rainer.invalid> (raw)
In-Reply-To: <5528EE66.8070305@gmail.com> (David Macek's message of "Sat, 11	Apr 2015 11:50:30 +0200")

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

  reply	other threads:[~2015-04-11 11:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 10:07 Corinna Vinschen
2015-04-10 21:13 ` Warren Young
2015-04-11  9:35   ` Corinna Vinschen
2015-04-11  0:00 ` Steven Penny
2015-04-11  9:40   ` Corinna Vinschen
2015-04-11 10:07     ` Corinna Vinschen
2015-04-11 16:26       ` Ernie Rael
2015-04-12  8:22         ` Corinna Vinschen
2015-04-11 10:23     ` Corinna Vinschen
2015-04-11 10:47     ` Steven Penny
2015-04-11 14:30       ` Corinna Vinschen
2015-04-11 16:05       ` Andrey Repin
2015-04-12 17:37         ` Adam Dinwoodie
2015-05-16  2:39   ` Steven Penny
2015-05-17  7:44     ` Duncan Roe
2015-05-19  7:52     ` Jiří Engelthaler
2015-04-11  8:47 ` Achim Gratz
2015-04-11  9:02   ` David Macek
2015-04-11  9:08     ` Achim Gratz
2015-04-11  9:51       ` David Macek
2015-04-11 11:51         ` Achim Gratz [this message]
2015-04-11 10:00     ` Corinna Vinschen
2015-04-11 12:36       ` David Macek
2015-04-11 14:31         ` Corinna Vinschen
2015-04-11  9:44   ` Corinna Vinschen
2015-04-11 11:11     ` Bryan Berns
2015-04-11 14:32       ` Corinna Vinschen
2015-04-11 16:05   ` Andrey Repin
2015-04-11 17:11 ` donmez
2015-04-12  8:35   ` Corinna Vinschen
2015-04-12 13:21     ` İsmail Dönmez
2015-04-12 14:25       ` Corinna Vinschen
2015-04-15 15:42         ` Corinna Vinschen
2015-04-16 10:20           ` Ismail Donmez
2015-04-16 11:03             ` Corinna Vinschen
2015-04-16 16:09               ` Ismail Donmez
2015-04-16 16:24                 ` Corinna Vinschen
2015-04-16 16:48                   ` Ismail Donmez
2015-04-17  7:30                     ` Corinna Vinschen
2015-04-17 10:06                       ` Corinna Vinschen
2015-04-17 15:17                         ` Ismail Donmez
2015-04-17 16:22                           ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878udydgsy.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).