On Wed, Nov 15, 2000 at 07:01:35PM +0200, Peter Pentchev wrote:
> On Wed, Nov 15, 2000 at 08:47:22AM -0800, Alfred Perlstein wrote:
> > * Peter Pentchev <[EMAIL PROTECTED]> [001115 06:19] wrote:
> > > All right, feel free to flame me a LOT for what follows :)
> >
> > No need for that. (yet) :-)
>
> ..possibly because I did not make my intentions clear enough :)
>
> > > There are situations (at least I could think of some :) where it is necessary
> > > to change a running process's credentials. I'm thinking specifically of the
> > > effective UID and GID, but I might have to tinker with the real and saved
> > > UID's, too.
> >
> > Well there's setuid for you.
>
> Hmm.. I've also received two private mails so far, pointing me to setuid().
> The problem is, I want to force a new UID on *another* process without
> its knowledge. setuid() only works on the process invoking it, so
> both the 'force' and the 'without its knowledge' part fall by the wayside :(
Yes, but what about the case where the process itself checks to see the uid
under which it runs, and modifies it's behavior accordingly? Think of a case
like below:
if (geteuid() != 0) {
...
ptr->field = (struct something *) malloc(BUF);
ptr->field->data = FOO;
..
}
and later in the code:
if (geteuid() != 0) {
...
free(ptr->field->data);
...
}
and the process starts with a uid != 0, but you change it's uid while it runs
[but before it reaches the second piece of code] to 0. It will incorrectly be
forced to derefence a NULL pointer [ptr->field] and gracefully core dump.
I think that you are indeed playing with fire here :)
- giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
