[ On Saturday, November 18, 2000 at 14:06:15 (-0800), Greywolf wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> ...and now that you have open_as(), guess what you've just done via
> fchmod() and fchown()? 8-D

Exactly.  Which is why you don't need/want chmod_as() and chown_as().
One new function of this nature is more than enough to add to the
current API, and it's already more than powerful enough.  What open_as()
is really doing here is just getting rid of the "access(); open();" race
condition.

> # If I were to redesign set-ID again I think I'd make it work in such a
> # fashion that the resulting process defaulted to running as the real user
> # and that sete*id() would be necessary to *temporarily* raise privileges
> # only for the next system call.
> 
> You've just condemned set-id programmers to the hell of not being able to
> re-use code in, i.e., their own library which they do share between
> common programs.  An awful lot would break.

No, I don't think so.  I would only require that programmers first call
something like a seteid() call somewhere before every system call that
needs it -- that would even cover most library calls that front system
calls too.

In any case this half-assed idea wouldn't cause 'an awful lot' of things
to break because it would be an entirely new paradigm and thus no
existing code would be expected to work in the first place!  :-)

> # -- this would make set-ID programmers more
> # aware of when they are using their privileges and might make it easier
> # for them to figure out when they can completely drop privileges.  I
> # would also make fork() always revert to the real-IDs just as if you'd
> # first called setuid(getuid()) -- i.e. no inheritance of privs!
> 
> That'd be a lose.
> 
> I seem to remember a Doug Gwyn quote that went something like, "UNIX
> does not prevent you from doing stupid things because then it would
> prevent you from doing smart things, too."

I can't think of many "smart things" that one might need to do which
can't already be done in other ways under my new paradigm.

After all, if you really want the child process to retain it's
privileges then you need only setuid(geteuid()) first.  What that does
is to force you to choose who the child process is going to run as.

Note that as things are now when a process exec()s another non-set-ID
binary it's saved-set-IDs are always clobbered to be equal to its
effective ID, but the effective and real IDs are left alone.  This means
that as it is now a set-ID programmer has to take extreme care to always
call setuid() before execve() anyway lest potentially un-audited code be
shouldered with the burden of dealing with a set-ID situation.  All I'm
doing in my proposal is making the default behaviour the safe, secure,
correct, behaviour -- I don't think I'm taking away too much rope.

In any case please note that for now I've tied the fork() idea to my
other half-assed idea above, so please don't forget that the whole thing
together changes the set-ID paradigm quite significantly and as a result
there's not really much concern about compatability with existing
practice.

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