From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by sourceware.org (Postfix) with ESMTPS id 8C8383857C7F for ; Fri, 7 Jan 2022 14:53:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C8383857C7F Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MQeI4-1mlPnC2bmo-00NmPB for ; Fri, 07 Jan 2022 15:53:20 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id E5DA7A8103B; Fri, 7 Jan 2022 15:53:19 +0100 (CET) Date: Fri, 7 Jan 2022 15:53:19 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: A notion about saving and restoring Windows file security info Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <4c5fda33-8f7e-53d2-85ce-28eb11cfb978@cs.umass.edu> <7cea7819-c03e-60c2-1acc-380b1bd0c18f@cs.umass.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:aeEXbQX2wAZ6Nf3aq20K7fFqhC4FhPjUGd/gI8He8D4nmx8JWom 02is4eQWqJ1+XKktaWQOfIYWoSBhBSMuDPNi4iVX9C3+NLJfxx98S4rwYWO0ZBxBmbT1bK0 x1eYWgq8oPIzxpsCGpxMQyZ9FbswLwXiojf97QFVgCg3COnq6w1m4YSdoUD4kk6eIoQOwdA R4xgsBbgaBHgxJHeJr0HA== X-UI-Out-Filterresults: notjunk:1;V03:K0:rG7Sry79erg=:TaQM9WuNykiE1I5bdTMxM7 YPzYRQz/+UhebpH4lTxHYY1D/ayWdOzg0HHhThN2gWmbG444s1hfCfA1t5V/Ic9O+5dTfOOMN I+cnH0lQeTmaq2E7wTmrx3VM+PQed9+gZaR/vnevGG9D9fXsfANLBNW5ZGUwwgiyCl3uRARTj lP/gdFT2IYS+Atd7b+VqMbrMmRwBpRp0DlcNdMTW0mabi8zCfI1Q5eBRg95vUYUbovUwt3uqs Mpw6p55nLql6OBMQI9JTvLWYnDTB+BAZv78RtxbngPyiI/jxXUiogbKVZ6IeTdurbGXhl3x7z LZrkk0uBteCAuifnnVRKaA8Kbf3znBJXK0dj6P1dDHHMKx2//co1oMrHZVKO6XsVGtnxFt4rn 4W/OxuzQt9MPbcXB0cY0JjkTFrD/OaT9OE3XxrjtQpilrqZz7w/NjjwGoEsUisZaH9nL7KE3n a96JRXVSPFYphHygAXZSDsw3isI3mV0qbV69vOgZrRJMsUTUdsW4aifBa4RT6D9vJBAMRO2XX 8Hs4Kl38mf+lKQALvdjHC0F+on4LU/fxZtOMzQvhipu/uDOF97DyTtPWuFydFSf2yK2dxQQuV iudtGBOoA+NNIBNsUhO+kWpIbXVyphd3tgnWrm0HCZ4Bbx4dt/+ar+J0AZwMr/nfkoBJnAJyQ 3tsS7EvUq3spW4tRLarzCHZMdglliRtYoj1bh1q2cAM2nJ9UFQZvMOlnl01QKbrg3P2LvYpAa /tKzNM2WwlHpOgiq X-Spam-Status: No, score=-85.8 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, 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@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: Fri, 07 Jan 2022 14:53:24 -0000 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