[2831] in Kerberos-V5-bugs
Re: krb5-libs/505: patch to make krb5 consistently use one set-effective-uid function
daemon@ATHENA.MIT.EDU (Evan Champion)
Thu Dec 4 15:25:33 1997
Date: Thu, 4 Dec 1997 15:24:36 -0500 (EST)
From: Evan Champion <evanc@synapse.net>
Reply-To: Evan Champion <evanc@synapse.net>
To: tytso@MIT.EDU
Cc: krb5-bugs@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
In-Reply-To: <199712041932.OAA00826@rsts-11.mit.edu>
On Thu, 4 Dec 1997 tytso@MIT.EDU wrote:
> Actually, no, seteuid() is not POSIX-approved. The only function which
> is defined by POSIX is setuid().
Ack, sorry I misread the manpage. It says:
The seteuid()
and setegid() functions are extensions based on the POSIX concept of
_POSIX_SAVED_IDS, and have been proposed for a future revision of the
standard.
> Seteuid() is also not enough, for those platforms which don't implement
> the POSIX saved-setuid functionality (which is OPTIONAL to implement).
> For example, if you simply use seteuid() to temporarily drop root
> privileges, and you're on a system which doesn't implement saved-setuid,
> there's no way to get root privileges back.
Hum. I think one could define seteuid() to be setuid(0); seteuid(X) in
this case. Or, the reverse of my patch could be used; always implement
things in terms of setreuid(). But I suspect seteuid() is the more
progressive of the two functions.
It looks like having a properly-defined HAVE_SAVED_IDS would be useful
here. You can't rely on _POSIX_SAVED_IDS; this is not set on 4.4BSD,
because setuid() does not implement saved ids, while seteuid() does. In
this respect, krb5_seteuid() is broken, because seteuid() is a perfectly
viable function for it to use on 4.4BSD, but it will never choose it
because _POSIX_SAVED_IDS is not defined.
I'm not exactly sure though how one can reliably find out if the seteuid()
is saved-id.
> Obviously, seteuid() is also not sufficent when you actually want to set
> the real-userid.
... which never happens, or at least if it does do it it uses setuid()
directly. You can see from my patches every single occurance of
seteuid()/setreuid() in Kerberos, and except in one function where
setreuid() was used to swap the real and effective uids, the real uid was
never changed.
> What was there a specific problem you were trying to solve with these
> patches?
Yes; setreuid() doesn't work on BSD/OS. In particular, you can use it to
switch to root, but from there you can't switch to any non-root user using
setreuid(). I noticed this in particular with ksu, but it may be a
problem elsewhere too. Once I forced seteuid() everywhere, everything
worked just peachy.
While I was running through the code to find all the setreuid()'s (to
change them to seteuid() so I could be sure they'd work), I found that
there was no consistency in how either seteuid() or setreuid() was being
redefined if it was not available, nor was there any consistency in the
order in which each function would be used (for example, some preferred
setreuid() to seteuid(), and some the opposite). That was when I decided
to change them to all use the same #define's, and in doing so fix the
preference order.
I have since thought about my solution, and decided that it would be
better to not use seteuid() as the set-effective function, but rather
krb5_seteuid(), and have krb5_seteuid() be defined to whatever is required
to get set-effective to work on that platform. This is because you might
get bizarre behaviour if you start on some new code and forget to #include
the seteuid() redefinitions; by using something with a totally different
name, there should be no confusion. The idea is still the same, however,
and when the next drop is released, I'll work something up.
Evan
