From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20681: Build failure [MSYS2/MINGW64, OSX] Date: Mon, 01 Jun 2015 18:05:07 +0300 Message-ID: <834mmrtqos.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1433171186 16711 80.91.229.3 (1 Jun 2015 15:06:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 15:06:26 +0000 (UTC) Cc: 20681@debbugs.gnu.org, eggert@cs.ucla.edu, nandryshak@gmail.com, angelo.graziosi@alice.it To: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 01 17:06:15 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 1YzRI7-00023h-EH for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Jun 2015 17:06:15 +0200 Original-Received: from localhost ([::1]:52882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzRI6-0003wm-L3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Jun 2015 11:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzRHz-0003wb-Nq for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 11:06:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzRHu-0004Kn-R6 for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 11:06:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzRHu-0004Kh-Mb for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 11:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YzRHu-0001om-Hk for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 11:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jun 2015 15:06: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.14331711346947 (code B ref 20681); Mon, 01 Jun 2015 15:06:02 +0000 Original-Received: (at 20681) by debbugs.gnu.org; 1 Jun 2015 15:05:34 +0000 Original-Received: from localhost ([127.0.0.1]:36296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YzRHR-0001nv-KP for submit@debbugs.gnu.org; Mon, 01 Jun 2015 11:05:34 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54082) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YzRHM-0001nL-4S for 20681@debbugs.gnu.org; Mon, 01 Jun 2015 11:05:29 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NP900B00TUT3W00@a-mtaout22.012.net.il> for 20681@debbugs.gnu.org; Mon, 01 Jun 2015 18:05:21 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NP900AP0TWWRO90@a-mtaout22.012.net.il>; Mon, 01 Jun 2015 18:05:21 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il 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:103435 Archived-At: > Date: Sun, 31 May 2015 21:18:37 +0200 > From: Andreas Grünbacher > Cc: Nick Andryshak , 20681@debbugs.gnu.org, > Paul Eggert , Angelo Graziosi > > > Emacs built with MinGW has the same functionality on Windows as Emacs > > does on Posix hosts: get a file's ACL as a text string, set a file's > > ACL from text string description, and copy ACL from one file to > > another. > > > > The relevant functions, acl_get_file, acl_set_file, acl_to_text, > > acl_from_text, and acl_free are implemented as part of Emacs. > > So those are the functions that gnulib is seeing? If so, then emacs > could provide > acl_delete_def_file as well, and everything will be fine again. Everything is fine already: I removed set-permissions.c from the MinGW build. While acl_delete_def_file could be added, it would be a stub that always fails, so I see no point in doing that, as long as Gnulib ACL code is effectively ignored on Windows. > 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. > 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. > > E.g., why not do something like the following instead: > > > > # ifndef HAVE_ACL_DELETE_DEF_FILE > > ret = -1; > > errno = ENOSYS; > > # else > > ret = acl_delete_def_file (name); > > > > # endif > > 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. > > 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. 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. > > After all, copying ACLs from one file to another is much more frequent > > and important an operation than setting ACLs from user-specified > > arguments. > > Probably, yes. > > > What's more, the assumption that if acl_get_file and acl_set_file are > > available, then so should be acl_delete_def_file is yet another > > obstacle, IMO gratuitous one. > > No, acl_get_file, acl_set_file, and acl_delete_def_file are all part of the > POSIX ACL API, and acl_delete_def_file is needed for directories. For Posix platforms, yes. I was thinking about non-Posix ones, where there's no such necessary linkage. > >> 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. IMO, a general-purpose program such as Emacs should not futz with the inheritance flags in Windows ACLs, because doing so makes it very easy to inadvertently make directories and files inaccessible or exempt from important operations like system-wide backup. Fortunately, Emacs doesn't need these capabilities, at least not explicitly on the acl_get_file and acl_set_file level. Once again, please don't take the above as some objection to your work, or request to make any changes for MinGW. They are just observations of a bystander at this point. Thanks.