From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Newsgroups: gmane.emacs.bugs Subject: bug#20681: Build failure [MSYS2/MINGW64, OSX] Date: Mon, 1 Jun 2015 18:18:43 +0200 Message-ID: References: <55671056.9030604@alice.it> <83oal4wq59.fsf@gnu.org> <55685B1B.1040507@alice.it> <55689A39.7080804@cs.ucla.edu> <5568C1C8.2090406@cs.ucla.edu> <83siaeuzzk.fsf@gnu.org> <83lhg6uuyy.fsf@gnu.org> <83oal0u8g0.fsf@gnu.org> <834mmrtqos.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1433175568 29537 80.91.229.3 (1 Jun 2015 16:19:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 16:19:28 +0000 (UTC) Cc: 20681@debbugs.gnu.org, Paul Eggert , Nick Andryshak , Angelo Graziosi To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 01 18:19:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YzSQj-0007yg-5b for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Jun 2015 18:19:13 +0200 Original-Received: from localhost ([::1]:53369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzSQi-0004NV-6S for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Jun 2015 12:19:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzSQe-0004NK-1K for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 12:19:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzSQZ-0002Hv-DZ for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 12:19:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzSQZ-0002Hp-8n for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 12:19:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YzSQY-0003YA-Od for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 12:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jun 2015 16:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20681 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20681-submit@debbugs.gnu.org id=B20681.143317553213630 (code B ref 20681); Mon, 01 Jun 2015 16:19:02 +0000 Original-Received: (at 20681) by debbugs.gnu.org; 1 Jun 2015 16:18:52 +0000 Original-Received: from localhost ([127.0.0.1]:36332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YzSQN-0003Xl-Dx for submit@debbugs.gnu.org; Mon, 01 Jun 2015 12:18:52 -0400 Original-Received: from mail-ob0-f182.google.com ([209.85.214.182]:35373) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YzSQL-0003XY-A7 for 20681@debbugs.gnu.org; Mon, 01 Jun 2015 12:18:50 -0400 Original-Received: by obcnx10 with SMTP id nx10so101905672obc.2 for <20681@debbugs.gnu.org>; Mon, 01 Jun 2015 09:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+uBuhIlBQq9o/pEmHL6CW63uZ/vmnZdROn2rCkyoY84=; b=bENKALnXEz5Es+NoFt/ubpmiTdHmwh+KYYdiUebbnalG7PpLWbS9To7b0SGrpQrJHh VAPQlfHa05h4ZGN0mXDei4kauOnKtVu7jghc0m6z0CBjemYcpv8kdCyUdG4sjb72sKu9 WLuHtWdfEYQKa8wX2gtYWS35uJwNgmKnjSUFzBCI2uURAa7FBrqMGN9CBXcWuzxS54ok 9dLvD8DGhQNppkpzRRIonMnZFJLvbdfIwuwM38xA+eUTsA1BRwO37W/f82HZsGwOphkh eAVKQ06N27vQ+DNf+jQ9TyA4b/Z6495RSqZMnQaz8PW8mBgt23qkUYUimnmR5uK8DoA+ bRPQ== X-Received: by 10.60.80.229 with SMTP id u5mr19030434oex.27.1433175523446; Mon, 01 Jun 2015 09:18:43 -0700 (PDT) Original-Received: by 10.182.143.72 with HTTP; Mon, 1 Jun 2015 09:18:43 -0700 (PDT) In-Reply-To: <834mmrtqos.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:103441 Archived-At: 2015-06-01 17:05 GMT+02:00 Eli Zaretskii : >> But shouldn't Windows ACL support be added to get_permissions() and >> set_permissions() proper instead of emulating Windows ACL support through >> the POSIX draft ACL interface? The _to_text() and _from_text() functions >> could be modified to take a struct permission_context argument; they could >> be moved into gnulib or remain part of emacs. > > What would be the benefit of doing that, though? You will see in the > Emacs sources that currently acl_to_text produces the Windows-specific > SDDL string representation of the file's DACL security descriptor; > making that Posix-compliant in order for those functions to be able to > work with the likes of acl_from_mode is an extremely non-trivial and > thankless job. You would add a Windows ACL to struct permission_context, add support for it to get_permissions and set_permissions, and add permission_context_from_text() and permission_context_to_text() functions. The _from_text and _to_text functions could initially only support POSIX and Windows ACLs, which would be what emacs supports today; support for other kinds of ACLs could be added later at any point. As a result, emacs would grow better acl support over time, and so would the other packages using get_permissions and set_permissions. >> As a side effect of that, cp in coreutils would then also do the right thing on >> Windows (if someone made coreutils build there again). > > If cp just copies the ACLs, it doesn't need all this machinery. It > just need to handle ACLs as an opaque object understood only by > acl_get_file and acl_set_file. There's a bit more to copying acls if you want to copy between file systems which support different kinds of acls (or no acls) in a reasonable way. The cp utility is dealing with this kind of problem, and I can't think of a lot of reason why that logic shouldn't be shared with emacs. >> Nope, the call is really needed. > > I believe you, but I still don't understand why this couldn't support > systems that don't have the notion of default ACL, or don't need to > remove it when the file in question is actually a directory. > > You might have in mind Posix platforms that adhere to the relevant > Posix draft, in which case it's exactly my point: this code makes it > harder for non-Posix platforms to support these routines when it's > easy to emulate acl_get_file and acl_set_file, but supporting addition > or removal of the default ACL is hard or ineffective/pointless. I'm talking *exactly* about systems which don't have POSIX ACLs. It doesn't make a whole lot of sense to emulate Windows as POSIX ACLs, and it makes no sense to emulate them as ACL_TYPE_ACCESS. If you emulate POSIX ACLs, then you need to emulate both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, or ACL_TYPE_EXTENDED instead of ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT. But even that isn't really all that useful; there is no reason why Windows ACLs can't be implemented as a new kind instead of forcing them through a POSIX-y interface. >> > More generally, copying ACLs from one file to another does not need >> > any analysis of what's in the ACLs being copied: it could simply treat >> > the ACLs as an opaque object, something whose structure and semantics >> > are known only to the innards of acl_get_file and acl_set_file. So >> > building qcopy_acl on top of get_permissions and set_permissions, >> > which are more flexible, and do require that knowledge, is IMO >> > fundamentally wrong, as it makes much harder to port this simple and >> > important Gnulib function to other platforms. >> >> I disagree. Have a look at struct permission_context; acl_get_file() and >> acl_set_file() is part of the POSIX draft ACL API but other platforms >> have totally different data structures and interfaces. Windows ACLs >> should be implemented as another kind of ACLs, not disguised as >> POSIX ACLs. > > See above: doing so is of course possible, but it's a lot of hassle > for very little, if any, benefits. It is very easy to provide on > MS-Windows the minimum emulation of Posix interfaces that allows to > (a) copy ACLs from one file to another and (b) convert ACLs to and > from text representation for human consumption or for logging. That's > all Emacs needs, and that's all most other programs will ever need. > Adding anything else to the soup raises the bar much higher, because > the semantics of Windows ACLs is very different. For starters, where > Posix platforms have 3 rwx access bits, on Windows there are 7 > standard access rights; mapping those 7 to the 3 Posix bits will at > best seriously limit what Windows programs can do with ACLs. And then > there are the issues with the ordering of ACEs in an ACL, with > implicit access rights via group membership, etc. etc. > > So I think the depth of compliance which is expected by > set-permissions.c is too much for Windows, way beyond the proverbial > 80-20 point. Adding Windows ACL support to get_permissions and set_permissions really doesn't take a whole lot more than copying the code from emacs into gnulib and testing the result. It's really not such a big deal. > There's also the minor (but important for Emacs) point of supporting > file names with characters outside of the current system codepage, > which Gnulib can only provide in UTF-8 locales, something that doesn't > exist on Windows. This has nothing to do with get_permissions and set_permissions. >> >> If it has acl_get_file and acl_set_file, where can I find >> >> documentation about what those functions do on MinGW? >> > >> > They do what you'd expect, but support only ACL_TYPE_ACCESS. They >> > know about ACL_TYPE_DEFAULT, but always return EINVAL for it, since >> > it's next to impossible (and not recommended) to have a directory on >> > Windows which has no default ACLs associated with it. >> > >> > You can see their sources in src/w32.c in the Emacs repository. >> >> That's just wrong. Windows ACLs can contain effective as well as inheritable >> permissions; the split between types as with POSIX ACLs doesn't exist. > > Not sure what you are saying here: which part of what I wrote is > "wrong", exactly? > > If what you mean is that ACL_TYPE_ACCESS could or should include the > inheritance flags, then that's what is currently implemented in Emacs, > but reporting or adding/removing those flags is not supported. The whole point of splitting POSIX ACLs into the two types ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT is to get rid of inheritance flags in ACLs. Having inheritance flags in ACL_TYPE_ACCESS or ACL_TYPE_DEFAULT is totally wrong. Windows doesn't have this split, and neither does ACL_TYPE_EXTENDED. Andreas