From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsrv.cs.umass.edu (mailsrv.cs.umass.edu [128.119.240.136]) by sourceware.org (Postfix) with ESMTPS id 9EAD13858425 for ; Wed, 5 Jan 2022 17:41:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9EAD13858425 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 Received: from [192.168.50.148] (c-24-62-201-179.hsd1.ma.comcast.net [24.62.201.179]) by mailsrv.cs.umass.edu (Postfix) with ESMTPSA id 2B49B40103AD; Wed, 5 Jan 2022 12:41:39 -0500 (EST) Reply-To: moss@cs.umass.edu Subject: Re: A notion about saving and restoring Windows file security info To: cygwin@cygwin.com References: <4c5fda33-8f7e-53d2-85ce-28eb11cfb978@cs.umass.edu> From: Eliot Moss Message-ID: <7cea7819-c03e-60c2-1acc-380b1bd0c18f@cs.umass.edu> Date: Wed, 5 Jan 2022 12:41:39 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 17:41:41 -0000 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