A notion about saving and restoring Windows file security info

[Corinna Vinschen]

On Jan  7 09:28, Eliot Moss wrote:
> On 1/7/2022 8:02 AM, Corinna Vinschen wrote:
> 
> > Reconsidered: Its a bit of effort for reasons outlined below.
> 
> Possibly ...
> 
> > No settings in that case.
> 
> I didn't entirely get your meaning, but I *think* you said if this
> is implemented, it should just return these "extra" things as suitably
> named attributed all the time.

What I meant is, no selectable option, as Sam pointed out in his reply.
Yes or No, not Maybe.

> >*Iff* we do that, we should provide the native ACLs in a consistent manner.
> 
> Yes, it should be consistent - but that doesn't rule out continuing the exist
> get/setfacl interface, for example.

Wait... that's an entirely different beast.

On Linux ACLs are implemented using xattrs.  The Linux (or rather,
deprecated POSIX) acl(5) API provides the means to access ACLs
independent of their actual implementation.  On Linux it uses the
getxattr/setxattr calls to access the DACL, on Cygwin it uses the native
NT and Windows APIs basically.  This API will certainly stay in place.

IIUC, you're looking for using xattrs to provide a direct means of
saving and restoring the Windows ACL.  This is different from the POSIX
ACL.  What I'm referring to in my reply is to provide a xattr with
the binary content of a Windows DACL verbatim.  That could be used
by a subsequent setxattr call to restore the Windows ACL verbatim as well.

Having said that...

> > I'm a bit concerned how this is supposed to work in cases where the user
> > uses the tool's 'restore xattrs' flag but is missing admin rights.  There's
> > also a potentially confusing result if you restore ACL xattrs on another
> > system.  The SIDs won't match and you can easily end up with an entirely
> > broken permission hirarchy.
> 
> If you're missing the rights, setting that "attribute" will fail and a
> reasonable tool will tell you.

It's not simple failing I'm concerned about.  If the file belongs to my
user and if I have WRITE_DAC access, I can restore the DACL.  However,
I'm typically not allowed to chown, and the resulting ACL should reflect
the fact that the owner didn't change.  But the verbatim Windows DACL
contains another user SID.  I didn't entirely think this through, but in
that scenario the underlying Cygwin code might have to tweak the Windows
DACL accordingly, and *that's* a complication which sounds the opposite
of funny.

> Restoring on a different system is not unlike extracting from a tar archive
> and asking for the uid/gid/perms to be preserved - caveat utilor, though a
> good tool would give some control.

If you have admin perms and ask the tool to restore xattrs, the DACL
will get written.  Windows does not check if the SIDs make sense on the
local system, because there's no notion of making sense.  On Windows,
any SID might be correct, e.  g. an account of another domain.  Maybe
it's not that much of a problem, but I remember NT4 times and how
complicated it was at times to restore useful permissions to a file with
broken ACL.

> > Also, to answer my own question, listxattr would have to list the xattr, of
> > course, otherwise backup tools wouldn't find the xattr and still not save
> > it.
> 
> Right.
> 
> >> Another question to ponder is whether an interface of the kind I am suggesting
> >> might also present NTFS ADSs (alternate data streams) as xattrs,
> >
> > See the thread starting at
> > https://cygwin.com/pipermail/cygwin/2022-January/250352.html
> 
> That does raise the interesting question of whether ADSs more appropriately
> should present a file-like interface or xattr-like one.  The latter would
> present an ADS as one (possibly big) blob, or else complicate the interface.
> There could still be a file-like interface, separately.  An xattr-like one
> might be good for transparent backup/restore.  More pondering required!

If with file-like interface you mean the file:stream expression for
filenames, than that's not an option.  As xattr interface it might be
a neat extension.


Corinna