[ On Friday, November 17, 2000 at 17:40:01 (-0700), Warner Losh wrote: ]
> Subject: Re: Addition to force open to open only regular files 
>
> In message <20001117223759.3D3874@proven.weird.com> Greg A. Woods writes:
> : I don't think O_REG_ONLY, O_RGONLY, or whatever will sovle the problem
> : sufficiently.  It works now, today, with devices, but as someone's
> : already mentioned, what about symlinks (I don't recall seeing a real
> : answer to that question yet).
> 
> It will allow the fstat after the open to deside if the file is
> readable or not.  At least that's the theory.  It will also allow one
> to know if the symlink race was tried.  It will also allow you to not
> open the devices that might have side effects.

Hmm... yes, but it seems a lot counter-intuitive.  Not that I want to
give the impression that writing set-ID programs can be done with one's
intuition alone -- just that it's something you'd have to be extremely
explicit about in every use to avoid confusion at some future time.

> : > Also, there's a desire to do something which we can add to 1.5. It's too
> : > late for 1.5 itself, but it's easier to add an open flag to 1.5.1 than a
> : > new system call.
> : 
> : If it's deemed safe to use this kind of test to determine if a process
> : is running set-ID:
> : 
> : 	if ((geteuid() == getuid()) && (getegid() == getgid())) {
> : 		/* process is not running set-ID */
> : 	}
> : 
> : then I'd say throw that in to the resolver code around the code that
> : implements $HOSTALIASES (and maybe $LOCALDOMAIN), and that'll be it.
> 
> That's not safe.  That's the whole reason for the issetuid() system
> call.  If the process does a setuid(geteuid()) early, then this test
> will fail to properly exclude things.

I don't know of any process in its right mind that would do
setuid(geteuid()), never mind early on.  That would be BAD.  I.e. I'm
not too worried about protecting processes from themselves if they do
BAD things like this.  Such a process still has the chance of sanitising
its environment before continuing on too, so I still don't see a problem
that isssetuid() will solve -- it might be convenient, but it's not
telling us anything we don't already know if we're already expecting to
be in a set-ID process.

In all other cases where the effective-ID and real-ID might be identical
then either the process has done setuid(getuid()), or the invoking user
is the same as the effective-ID.  In the first case there is no danger
(other than breaking naming relationships) from $HOSTALIASES any more,
and in the second case the invoking user's already got the power to
trash whatever they want in easier ways than tricking the set-ID program
and so, well, their rope's just made a little longer, but not by much.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>