unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: wingo@pobox.com, ludo@gnu.org, guile-devel@gnu.org
Subject: Re: Support open-process and friends on MS-Windows
Date: Tue, 05 Jul 2016 03:44:15 -0400	[thread overview]
Message-ID: <8760sk34xc.fsf@netris.org> (raw)
In-Reply-To: <83y45jqt5y.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 Jul 2016 06:47:37 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark H Weaver <mhw@netris.org>
>> Cc: ludo@gnu.org (Ludovic Courtès),  wingo@pobox.com,
>>   guile-devel@gnu.org
>> Date: Sat, 02 Jul 2016 19:02:08 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > +# define getuid()              (500) /* Local Administrator */
>> > +# define getgid()              (513) /* None */
>> > +# define setuid(u)             (0)
>> > +# define setgid(g)             (0)
>> 
>> As I've said before, I'm not comfortable with these definitions.  These
>> are not operations that can be safely ignored.  If we cannot do a job
>> that's requested of us, we should raise an exception.  We should not
>> make numbers up out of thin air and pass them off as fact, nor should we
>> claim to have successfully done a job that we are unable to do.
>> 
>> More to the point, we should not assume that the caller's requests are
>> unimportant.  Feigning success on ignored requests and fabricating
>> misinformation might be okay in some cases, but in other cases it is
>> likely to lead to security holes and other bugs.  For example, a common
>> pattern is to use 'setuid' to drop privileges before running some
>> untrusted code.  We must not silently ignore such requests.
>
> [...]  All other applications ported from Posix platforms that I
> know of do something like the above, and I have yet to hear a single
> complaint.

Most applications do not expose get*id/set*id to other programs as part
of their public API.  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.

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.

(2) that security flaws would be extremely unlikely to arise from your
    definitions.

(3) that for the overwhelming majority of call sites, your definitions
    lead to correct behavior on MS-Windows.

I'm skeptical of all three.

> 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.

      Mark



  parent reply	other threads:[~2016-07-05  7:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24  9:51 Support open-process and friends on MS-Windows Eli Zaretskii
2016-06-24 10:45 ` Andy Wingo
2016-06-24 13:20   ` Eli Zaretskii
2016-06-24 11:49 ` Ludovic Courtès
2016-06-24 13:25   ` Eli Zaretskii
2016-06-25  9:11     ` Eli Zaretskii
2016-06-25  9:51       ` Andy Wingo
2016-06-25 10:22         ` Eli Zaretskii
2016-06-25 13:02           ` Ludovic Courtès
2016-06-25 13:20             ` Eli Zaretskii
2016-06-25 13:31             ` Eli Zaretskii
2016-06-25 14:43               ` Andy Wingo
2016-06-25 15:01                 ` Eli Zaretskii
2016-07-02 23:02               ` Mark H Weaver
2016-07-03  3:47                 ` Eli Zaretskii
2016-07-03 17:36                   ` Eli Zaretskii
2016-07-05  7:44                   ` Mark H Weaver [this message]
2016-07-05  8:04                     ` Ludovic Courtès
2016-07-05 15:56                       ` Eli Zaretskii
2016-07-11  8:09                         ` Ludovic Courtès
2016-07-11 14:49                           ` Eli Zaretskii
2016-07-05 15:51                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8760sk34xc.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=eliz@gnu.org \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).