From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.devel Subject: Re: Support open-process and friends on MS-Windows Date: Tue, 05 Jul 2016 18:51:20 +0300 Message-ID: <83r3b8nkw7.fsf@gnu.org> References: <834m8i3off.fsf@gnu.org> <877fde958i.fsf@gnu.org> <83wple1zym.fsf@gnu.org> <83ziq9zl8l.fsf@gnu.org> <87eg7lbnpi.fsf@pobox.com> <83y45tzhyn.fsf@gnu.org> <87twghs9ot.fsf@gnu.org> <83r3blz96w.fsf@gnu.org> <87inwn3aq7.fsf@netris.org> <83y45jqt5y.fsf@gnu.org> <8760sk34xc.fsf@netris.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1467741023 2252 80.91.229.3 (5 Jul 2016 17:50:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 17:50:23 +0000 (UTC) Cc: wingo@pobox.com, ludo@gnu.org, guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jul 05 19:50:17 2016 Return-path: Envelope-to: guile-devel@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 1bKUUC-0004UP-T9 for guile-devel@m.gmane.org; Tue, 05 Jul 2016 19:50:17 +0200 Original-Received: from localhost ([::1]:56756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKUUC-0001vF-4l for guile-devel@m.gmane.org; Tue, 05 Jul 2016 13:50:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKSdt-0001r6-8o for guile-devel@gnu.org; Tue, 05 Jul 2016 11:52:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKSdq-0006qO-MW for guile-devel@gnu.org; Tue, 05 Jul 2016 11:52:08 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKSdk-0006o0-Tn; Tue, 05 Jul 2016 11:52:00 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3267 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bKSdg-0002C2-6O; Tue, 05 Jul 2016 11:51:58 -0400 In-reply-to: <8760sk34xc.fsf@netris.org> (message from Mark H Weaver on Tue, 05 Jul 2016 03:44:15 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18465 Archived-At: > From: Mark H Weaver > Cc: wingo@pobox.com, ludo@gnu.org, guile-devel@gnu.org > Date: Tue, 05 Jul 2016 03:44:15 -0400 > > Most applications do not expose get*id/set*id to other programs as part > of their public API. Emacs exposes getuid, getgid, geteuid, and getegid, has been doing that for a very long time. See the functions user-id, user-real-id, group-id, and group-real-id. > When they are kept private, such hacks are far more defensible, > because it is possible to examine every call site and thereby > determine whether any harm might be caused by silently ignoring > requests and returning bogus results. > > In the case of Guile, you are asking us to expose these dishonest and > potentially dangerous definitions in our public API, and therefore to an > unbounded set of programs and use cases, not to mention public scrutiny. I don't see a significant difference between these two classes of use cases. IME, when someone needs the results of getuid etc. in Lisp, Scheme, or some other high-level language, they use them in the same way as one would do that in C as part of some primitive. After all, what other reasons could you imagine for using these values, except to write code in Scheme to do something similar to some primitive, but with a quirk? All the rest of the applications of these values I could think of (e.g., scanning /etc/passwd etc.) are not relevant to Windows anyway, since these facilities don't exist there in the form and format they do on Posix platforms. If you can think of some other kinds of application that might need these values, please describe them. > Before I would consider doing this, I would need to be convinced of > three propositions: > > (1) that get*id/set*id are used so frequently in Guile programs that it > would be unreasonably onerous to examine and modify each call site > to handle the MS-Windows case. getuid is used in boot-9.scm, so if it's unavailable, we cannot build Guile without making changes in the Scheme code. I don't know if that convinces you, and I have no practical way of counting their uses in Guile programs outside Guile itself. But even if the frequency is not high enough, what would be the practical alternative? Guile is an extension language, so we cannot possibly go out and fix all those uses, as they are not confined to a small number of known packages. > (2) that security flaws would be extremely unlikely to arise from your > definitions. setuid and setgid are defined to no-ops, so their security flaws are by definition nil. What kind of security flaws could arise from getuid and getgid, as I proposed to define them? Windows will not allow access to protected files regardless of the user/group ID we use, so I think these, too, have no security related issues that I can think of. > (3) that for the overwhelming majority of call sites, your definitions > lead to correct behavior on MS-Windows. I can tell that they survived the Guile test suite. More generally, the get*id values are just numbers that have no implication on code correctness. _Any_ scalar values returned by these functions on Windows will not be correct, because the corresponding Windows values are variable-length arrays (called Security Identifiers, or "SIDs"). Moreover, even if we do return the full SID to Guile, there's no way of using them in any Guile API because those APIs are modeled on Posix, which expects a single scalar value. So I think doing something like I suggested is really the only practical solution -- return some plausible number whose only real use could be to display it. > I'm skeptical of all three. I know. And that's what makes this experience so frustrating for me: you remain skeptical whatever I say, even though this dispute has been going on for a couple of years. > > Raising exceptions in these cases will simply get in the > > way of writing portable Guile programs, because the application > > programmer will have to work around the exception in Guile code, > > That's exactly what *should* be done, because only at the application > level is it possible to reliably determine how to properly handle the > absence of these operations. IME, the considerations on the application level will invariably be exactly the same as what I suggest: either don't call the API or ignore the result. Here's a relevant example: a Windows port of GNU 'cp'. I'm trying to recursively copy a directory: D:\usr\eli\data>cp -pvr foo bar `foo' -> `bar' `foo/#bug.m#' -> `bar/#bug.m#' `foo/bug.el' -> `bar/bug.el' `foo/bug.m' -> `bar/bug.m' cp: failed to preserve ownership for `bar': Permission denied ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The error happens because the person who ported the program didn't make 'chown' and its supporting code a no-op on Windows for directories. The result: infinite annoyance for users, and for no good reason at all, because Windows copies the NTFS security permissions by default. In this case, the error is not fatal, but that's just sheer luck. Suppose someone would like to write 'cp' in Guile Scheme -- what do you envision they will want to do with 'chown' on MS-Windows, if they want the result to be better than the above? The absolute majority of Guile programs are written by people with only Posix background, they don't know enough about Windows and don't care about it. We cannot expect them to figure out all these subtle issues and solve them in Scheme -- that's simply not going to happen. What will happen is that Guile programs that use these APIs will simply be broken on Windows, and for no good reason at all, as I attempted to explain several times in so many words. Do we really want that? I hope not.