X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org E9AE73857C76
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1641560576;
	bh=Z9Z74ahI0XJDr7WAa4LWkjc3NDaxXshRwjUAAGv5RUA=;
	h=Date:From:To:Subject:References:In-Reply-To:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	Reply-To:From;
	b=VWOhITCWokusHDhKGLzJ84rHIi1+zMWKJxKFov127tEiVehQ/EqLSDOJ+tSnEMdjp
	hFTHMLMuQ2ou0SW5mYAQqDD2L5IUyd3pRekdBkHFDI6CgjK41svBOuICJRc1a8iYz4
	jhSTjyr5xmTw6LJXhMRA3Y/8wMjd/68lpPpYZVhw=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 64053385802E
Authentication-Results:	sourceware.org;
	dmarc=fail (p=none dis=none) header.from=cygwin.com
Authentication-Results:	sourceware.org; spf=fail smtp.mailfrom=cygwin.com
Date:	Fri, 7 Jan 2022 14:02:24 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: A notion about saving and restoring Windows file security info
Message-ID:	<Ydg54LL6e8E1aWTP@calimero.vinschen.de>
Mail-Followup-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>
MIME-Version:	1.0
In-Reply-To:	<7cea7819-c03e-60c2-1acc-380b1bd0c18f@cs.umass.edu>
X-Provags-ID:	V03:K1:NZB89Apb4aEcMuYsotKfnXpChBUvy4iCUBn93NL4JVMxQd/96b0
	Ln413AixgKUOHuQ8tE5iw4Qys/qE6WC+kYQTtYtSRxReA7zwRkVO48J6/DL/LvMdQ/mhqrQ
	XGblpZHj7iJ7gT/WzSSL21ylSoBDUzxc7RrEDOdaplGJWu9Cr3ZXyGu4RqhJpnh45H5NWG9
	wGjFji5TWqCgWPMOQmSzA==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:qIMGf480FVI=:dOXoTOsS9suHXw5hXQgp4h
	+FVs32hq9Y2zERr9OdHl6xlJDC1/bJUJsusP8wB2uWWvEoePnCseKoe2G4LksqITFiY4eWLfq
	+QqieksfpLzwpEI/VP8X/i1AmJsW1h0ES+A8NdSlMQEAJNmxicUTFH3B3CwISCi+h4TWxxxik
	bqU/jSVj1uvMJFev5F1EFQyuiCil7fk66hixyd96uv0fJW7PNPoPwhL+SFmREhO2qQTAhJVBA
	pAKWGNqLkCuvBgokdXdiUsPGCHU7cm7IlFiHPApM26lmMotg2H4EVGfEui9IK2DCWVX+E7pxN
	QkpBq010O5qU7EoSkhZhkdgM/0WGmCGAfWXFt2eszzHqwgc0Y5r64ZamRfD08F2a4EF0UHWaV
	iJ+m4NDrrd3PL1l5+kY6RCsiFmkZpUrP2s4sPRsW84r2ibDdAliNeGUpUUSlnlDagvCmaM9AJ
	ons1dH0Q+jBYSkMoKorFYT550oS2r3Tu9F86z9C/YYGa+lvsVHWDLWmqXBphRD9N+AQH1OYcr
	lEY3yWfccMjFKVF/SQXqCLfsjqg/Zw0rvQIrTilKHpasNIgE6xkcQpIggnFBIouUsT7V4IgyU
	X/ZbVipIZfcvH1QCnRWyyf8CXgWdX9ryF0AH6Eu9c/ELQOj8+7rr6PLL12pK3J40GSzQNU5Dv
	BZKreQLCROb30HjuZMmTlihJfMfPE9UKL8YJTRQ5uFdMJKhaoa1Ch8UBRKkEFHYAulY2cvPiY
	mr/v3BUh9nSqr9Nl
X-Spam-Status:	No, score=-82.4 required=5.0 tests=BAYES_00,
	GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_SHORT,
	RCVD_IN_MSPIKE_H2, SPF_FAIL, SPF_HELO_NONE,
	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:	cygwin AT cygwin DOT com
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 Jan  5 12:41, Eliot Moss wrote:
> On 1/5/2022 5:34 AM, Corinna Vinschen wrote:
> > On Jan  4 22:45, Eliot Moss wrote:
> >> [...]
> >> 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
> >
> > It would be possible with not too much effort.

Reconsidered: Its a bit of effort for reasons outlined below.

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

No settings in that case.  *Iff* we do that, we should provide the native
ACLs in a consistent manner.

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.

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.

> 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?)

That's just for represent the POSIX permission bits.

> 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

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


Corinna

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