On Fri, 2 Aug 2002, Greywolf wrote:

> On Fri, 2 Aug 2002, Ben Harris wrote:
> # OTOH, the POSIX definition of exec() is quite likely to change to allow
> # implementations to re-open FDs 0, 1 and 2.  Up until 1003.1-2001, this is
> # forbidden, but 1003.1-2001/Cor 1-200x will permit it for setuid or setgid
> # executables, and a future revision might extend this to all executables.
>
> I don't think there's any business changing these semantics, myself.
> Are we going to continue to dumb down the API so that programmers can
> be lazier and less aware of what's going on?  I'll tell you right now
> that anyone who designs to 1003.1-2001/Cor 1-200x will be in for a
> large reality check when programming on a legacy system (where legacy
> might be only a year out of date).

You're wrong.  Note that the proposed correction only _allows_ the
implementation to re-open those descriptors.  Applications will still have
to be able to cope with implementations that leave FDs 0, 1 and 2 closed;
they just won't be able to rely on that any more if the image being
exec'ed is setuid or setgid.

> I'm sorry, am I *really* blowing smoke here?  Am I the only one who
> is perceiving this sort of automagic fd mangling to be A Bad Thing?

I think it's bad, but I'm not sure the security advantages don't outweigh
that for setugid programs.  It certainly seems ambiguous enough that I
think it's right for POSIX to permit it (especially since Linux and *BSD
do it already).

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>