X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 129683857C4F
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=cs.umass.edu
Authentication-Results:	sourceware.org; spf=pass smtp.mailfrom=cs.umass.edu
Subject:	Re: A notion about saving and restoring Windows file security info
To:	cygwin AT cygwin DOT com
References:	<4c5fda33-8f7e-53d2-85ce-28eb11cfb978 AT cs DOT umass DOT edu>
	<YdV0KNw+hZ5iS1AC AT calimero DOT vinschen DOT de>
	<7cea7819-c03e-60c2-1acc-380b1bd0c18f AT cs DOT umass DOT edu>
	<Ydg54LL6e8E1aWTP AT calimero DOT vinschen DOT de>
From:	Eliot Moss <moss AT cs DOT umass DOT edu>
Message-ID:	<d3838e15-8d55-2127-3c22-6f17189eb438@cs.umass.edu>
Date:	Fri, 7 Jan 2022 09:28:36 -0500
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
	Thunderbird/68.12.1
MIME-Version:	1.0
In-Reply-To:	<Ydg54LL6e8E1aWTP@calimero.vinschen.de>
X-Spam-Status:	No, score=-3.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_SHORT, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS,
	TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version:	SpamAssassin 3.4.4 (2020-01-24) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	moss AT cs DOT umass DOT edu
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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.

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

 > 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.  There may also be file systems that don't
support security descriptors, and trying to restore there would also fail.
The same might be true of xatts generally - not all file systems support
them.

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.

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

 >> 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:
 >
 > https://man7.org/linux/man-pages/man7/xattr.7.html
 >
 > Right now, all xattrs are treated by Cygwin as if they are in the "user"
 > namespace.  Ideally the ACL xattr would go into the "system" namespace,
 > but NOT use the system.posix_acl_access name.  Perhaps something like
 > "system.windows_acl_access"
 >
 > If you want to take a stab at it, see the file winsup/cygwin/ntea.cc.
 > It handles reading (function "read_ea") and writing (function "write_ea")
 > of EAs, and it provides the external POSIXy calls {l,f}getxattr,
 > {l,f}listxattr, {l,f}setxattr and {l,f}removexattr.
 >
 > One problem is currently that the handling of the "user" namespace
 > is hardcoded.  That needs a bit of mellowing.

Thanks for the pointers - I may take a look at it!  Eliot

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -