Re: A notion about saving and restoring Windows file security info

[Eliot Moss <moss@cs.umass.edu>]

On 1/5/2022 5:34 AM, Corinna Vinschen wrote:
 > On Jan  4 22:45, Eliot Moss wrote:
 >> Dear Cygwiners - Maybe this idea has been discussed before, and I can't say I
 >> exactly have a specific application in mind, but I was wondering about how one
 >> might achieve reliable backup/restore of files on a Windows system via a
 >> backup program written to the POSIX interface and ported to Windows via
 >> Cygwin.
 >>
 >> The idea is this: expose the Windows file attributes (such as system, archive,
 >> hidden, etc.) as well as security descriptors (such as managed by icacls), via
 >> specifically named extended attributes, those read/written by get/setfattr.
 >> The Cygwin library could be enhanced to "know" the special names of these
 >> attributes and use the appropriate, different, underlying calls to get/set
 >> them.
 >>
 >> Is this a crazy idea?  A useful one?  (How useful?)  What implementation
 >> effort would be required?
 >
 > It would be possible with not too much effort.  That would need a bit
 > of discussion, for instance, do we want to show up the native ACL in
 > listxattr?

Thanks for the quick response, Corinna!

One thing I am aware of is that the intent of xattrs is to allow applications
to attach metadata to items in a file system (inodes, essentially, right?)
that are meaningful to the applications but that do not affect the basic file
system semantics.  Since Windows file attributes (A, H, S, etc., bits) and
security descriptors *do* affect semantics, this would admittedly warp things
slightly.  Therefore, my thought is to make the presentation of these
attributes by attr_list (is that the canonical call?) and probably also the
special interpretation of them for get/set, controllable in some way.  The
means of control that occurs to me is an environment variable, or a flag
within the CYGWIN env var.  Other folks more deeply involved in Cygwin library
code, etc., may have a more informed notion of the best way to control this,
but it strikes me as one of those things that you would have to ask for.

As a side point, I have discovered that xattrs are used by WSL to record uid,
god, and mod information.  (While uid and gid are obvious, I am less certain
about mod - probably chmod type mode bits, but might have to do with
modification time?)

Another question to ponder is whether an interface of the kind I am suggesting
might also present NTFS ADSs (alternate data streams) as xattrs, if
requested.  The SysInternals "streams" program can manipulate them, though it
does mention that the program uses an undocumented native function to obtain
the stream information.  Cygwin cp, unsurprisingly, does not copy such
information, while cmd's copy command *does* (maybe a little surprisingly).  I
am aware that ADSs have security implications because they are so hidden from
users.  Adding this functionality would make it easy to use ordinary Cygwin
tools to find and remove any ADS of concern, etc.

Another design question is the names to use for these "magical" xattrs.  For
generality, if the feature is turned on, it might be good to add a prefix to
the names of real xattrs when getting/listing, that would be stripped off when
setting, and would of course be different from the prefix(es) for the
"magical" attributes.  For example, we could use:

- POSIX_ as a prefix for each regular xattr name
- WindowsAttrs as an attribute that capture all attrs, for simplicity, though
   we could also represent each of them separately as an attribute with no
   value, present only when the indicated attribute is set
- WindowsSDs for the security descriptors, a single attribute since order
   matters
- WindowsADS_ as a prefix for each ADS

In principle, each of Attrs, SDs, and ADS_ could be separately controlled, if
we think that is important (might be).

Those are my thoughts for now.  Sorry this is longish ...  Eliot