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]


Let me take a try on Achim's case with/refining the "alternative
idea"; this seems one of the kinds of cases that it is intended to

(Corinna, I hope at least some of the ideas here prove helpful to you,
and my posting this isn't (too) annoying.  Again, please
expect/forgive glitches as I'm not an expert on the internals of the
Cygwin library nor are file ACLs directly my area of expertise.  I've
included a lot of detail to try to see for myself if the pieces would
seem to all fit together properly, but to whatever extent those
details don't match possible reality, please try to see the abstract
idea/goal of supporting coexisting purely Windows-behaved and purely
Posix-behaved ACL entries.)

(Achim, I would be interested in hearing how well this approach would
seem to serve your needs/desires; there's a summary of the resulting
behavior for this case in the last main paragraph below.)

>> On the source tree the file owner (a domain user) doesn't have any
   rights, access is granted by one of the share groups (separately
   for read-only and modify access) and the filer admin group (modify
   access plus a few more permissions).  None of the share groups have
   permission to modify the DACL and everything gets inherited from
   the root node of the share (it's a NetApp, but I don't think that
   factors into that problem other than being the standard setup on
   these files apparently).

Here the "share group"(s) and "filer admin" seem examples of ACL
entries that are intended to behave following Windows, not Posix,
behavior.  I would expect the most desired behavior would be that they
would be inherited onto any newly-created files in those directories
following Windows' behavior, without at all impacting Posix behavior
such as whether (creation mode & ~umask) should be applied.  That they
would best not be impacted at all by chmod, or by setfacl creating a
Posix mask.  And that Cygwin/GNU tools such as rsync, also cp, tar,
etc., would best not carry these non-Posix-behaved/Windows-purposed
ACL entries from one directory subtree to another, but rather carry
across only Posix-behaved permission mode and "extended ACLs" plus
fold in whatever non-Posix to-be-inherited entries are present on the
target directory.

To achieve that, in this "alternative idea" the correct Posix mode for
this particular (extreme) case described by Achim would be --------- =
0000.  Similarly, getfacl would not show the "share group"(s), "filer
etc. ACL entries in this example at all (none of these are the primary
group, none of these are created with new-version setfacl).  The
impacts of these non-Posix-behaved ACL entries would be visible via
Cygwin/Posix APIs only the same as Linux shows impacts of root's
"magic" rights.

I would expect the lack of visibility of all granted permissions to be
an aspect some folks won't like about this "alternative idea" model,
but it seems necessary for ~/.ssh and similar cases to behave as
multiple people seem to be requesting, for chmod to have the visible
effects that it should without actually impacting these
non-Posix-behaved ACL entries, and for (creation mode & ~umask) to be
applied or not based on whether there are any Posix-"extended ACLs"
group/default entries but not impacted by non-Posix-behaved ACL
entries.  icacls would be the program to use if wanting to see
non-Posix-behaved ACL entries, tho perhaps getfacl could have an
option with some special-case code involved to be able to display
these, ideally marked as '#non-Posix' or some such.

At the Windows ACL level, this case does point out the need to be
quite careful about ordering.  Assuming Windows stops on the first
match it finds for an ACL entry the current user token and desired
kind of access matches, it would seem the non-Posix-behaved ACL
entries need merely to be kept earlier in the ACL than any
Posix-masked entries to avoid being impacted by the Posix-mask DENYs.
I've also thought through a little more re non-Posix-behaved DENY
cases; I now think they can coexist with Posix-behaved masking if we
locate the NULL SID carefully and choose (as I think is likely what'd
be most wanted by the Windows administrator) that any
non-Posix-behaved DENY should have priority over any Posix-behaved
permission grant.

Thus I'm thinking the best ACL ordering would be

  non-Posix-behaved ACL entries
  primary group
  other Posix-behaved users/groups (all referred to below as "groups")

To-be-inherited markings/entries should be kept in/following the same
active-for-this-file case/SID above, in particular, all
to-be-inherited-as-non-Posix-behaved ACL entries would precede the
NULL SID marker, Posix-behaved default entries after.

The Posix-behaved group entries should have a DENY preceding their
ALLOW if and only if by Posix rules a mask should exist.  The value of
the mask seems just the inverse of what the DENYs deny, which it seems
can be written the same for all the Posix-behaved groups without being
dependent on what permissions that group's ALLOW would have.  If any
DENY are present for Posix-behaved groups, they would all be expected
to represent the same one mask value, so there would seem no
importance to the ordering amongst Posix-behaved groups other than
that the related DENY precede each ALLOW.  Representing the mask
within the NULL SID entry also as Corinna wrote about earlier would
seem not necessary, but not harmful.

When reading a Windows ACL, the Cygwin library would start off
processing the types of ACL entries it has historically treated as
owner, primary group, and others, but simply ignoring all other
entries unless/until it sees the NULL SID marker.  At that point it
would process all the remainder, treating them as Posix-behaved.

When writing a Windows ACL, Cygwin would want to start by
copying/keeping existing ACL entries the file/directory has, but
filtering out any it considers owner/primary group/others, until it
hits the end of the ACL or the NULL SID entry.  At that which point,
stop copying what previously exists and instead write values per the
now-desired Posix mode and Posix-behaved set of ACL entries.  Whether
the copying/keeping of early entries should remove any
non-Posix-behaved ACL entries with the same SIDs as Posix-behaved ones
that are to be written seems a choice that could be made in either

This would all seem to work pretty well assuming the non-Posix-behaved
ACL entries are always created on a directory tree before Cygwin
starts writing into it.  I am uncomfortable tho about what would
happen should someone apply icacls or Windows GUI changes *after*
Cygwin has created an ACL with Posix-behaved additional groups or
defaults.  I'd expect problems, especially with the Windows GUI if I
recall correctly that it reorders ACL entries.  But even using icacls
to add a new non-Posix-behaved entry would appear to be difficult, as
it doesn't seem to have any "put this first" kind of option that I
spot, rather only wants to keep all ALLOWs after all DENYs.  Cygwin
might provide some special option/code in setfacl or some distinct
program to help maintenance, but a Windows admin might just use the
Windows tools regardless, causing effective corruption.

To ease this concern, the NULL SID should be written preceding the
Posix-behaved items if and only if there are any Posix-behaved added
groups, Posix-behaved defaults, or Posix mask present.  No NULL SID
should be written if only non-Posix-behaved ACL entries plus simple
owner/primary group/others Posix mode permissions need to be
represented.  This way icacls and Windows GUI would remain safe for
use modifying any file/directory that has not had explicit new-version
setfacl activity; any new ACL entries they'd create would be properly
treated as non-Posix-behaved.  Reordering might mess up the
owner/primary group/others ordering necessary for precise Posix
semantics, but that would seem an already existing problem and for the
most typical cases of naturally decreasing rights not a real concern.

Summarizing for Achim's particular case, the behavior would be simply
that the target new files/directories would get only ACL entries as
defined by the non-Posix-behaved to-be-inherited ACL entries of their
target parent directory, followed by an ALLOW of (Rc,S,RA) to each of
file owner, primary group, and Everyone, representing the 0000 Posix
mode (assuming rsync is creating target files/dirs with, or after
creation chmods them to, the 0000 Posix mode matching the source; else
(creation mode & ~umask) would be represented).  No other ACL entries
from the source files would be copied over to the targets.  For this
case, no NULL SID nor any DENYs would be created.

Thanks again for considering these thoughts.

Problem reports:
Unsubscribe info:

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