Re: Support open-process and friends on MS-Windows

[Eli Zaretskii]

> From: Mark H Weaver <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> 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.