in reply to Doing things as a different user

I cannot tell you how dangerous this is.

Probably, the best way would be to write a request into a database that has the specific required changes, then have a root daemon vet the changes then fork a child that becomes the requested user. You've got to have an intermediate like that so that you don't have a setuid root web process, which opens up many cans of worms.

Even then, how are you authenticating the user to the web process? I can't imagine having a low-privileged user temporarily have authentication credentials to pass on to the database either. Ugh.

Really, why are you doing this from the web?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

  • Comment on •Re: Doing things as a different user

Replies are listed 'Best First'.
Re^2: Doing things as a different user
by aufflick (Deacon) on Sep 27, 2004 at 01:04 UTC
    On consideration, we have decided to maintaing an audit trail by including the username in the supplied comments instead.

    It's not as robust auditing, but it's a load less pain. And despite my posturing I also intensly dislike invoking anything setuid from a webserver.

    Of course if the clients are windows, I could just embed the executable code in a jpeg ;)

    PS: I'm honoured to have the great Randal reply to my question - and in Australian Standard time too!

Re^2: Doing things as a different user
by aufflick (Deacon) on Sep 27, 2004 at 00:40 UTC
    Well, it's an intranet on a private lan, and the logged in users have already authenticated with their database password (which by the magic of LDAP is the same as their unix password).

    The main problem is that there is no way (I can find) to coerce Rational ClearCase to log an action as any user other than the euid.

    I'm not exposing any security problems I can see, because the username and password they supplied on login actually allows them to login to th unix box in question via ssh if they really wanted to.