Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Privilege elevation

by Uruk (Novice)
on Jan 21, 2003 at 00:19 UTC ( #228534=perlquestion: print w/replies, xml ) Need Help??
Uruk has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to write a simple CGI to help end-users configure a program on our machine, spamassassin to be specific. This program allows user config files in $HOME, and my CGI is going to need to read/write these files. Unfortunately the configuration files can't "include" other files elsewhere that the CGI writes, so my only option is probably going to be to edit the user's file directly from the CGI, which I really don't want to do. I'd prefer to create files the CGI program owns, and then set up user configuration files to just "source" those, but that doesn't seem possible.

Still, I can't think of anything better. Sure, I could make all user directories world readable and their configuration files world writable, but that's a really bad idea. I don't want to shoehorn all users into the same group and then give the configuration files group priveleges.

So the question is, is there a way to do the equivalent of "su" in perl to allow switching to another user ID? More importantly, is there a way of doing this safely? (Of course I'm going to be using standard techniques including taint checking and so on) One thing I'm definately not going to do is make the CGI suid root. :)

Or am I missing something and is there an easier way out?

Replies are listed 'Best First'.
Re: pprivilege elevation
by grantm (Parson) on Jan 21, 2003 at 03:32 UTC

    Sudo can do this sort of thing for you. It's an executable so you'd need to use system or backticks to run it.

    You'd need to split your logic so that the user interface is handled by the CGI script and updating the config file is handled by another script ('Script-B'). Then you'd configure the sudoers file to allow the anonymous web user (typically 'apache' or 'nobody') to run Script-B under another the user's real user id (with no password prompt and no lecture). Details of the required change would be passed to Script-B via the command line or STDIN. This assumes you've authenticated the user somehow before you proceed with the update.

    Sudo itself is a setuid-root program but I believe it is well audited code - it's certainly widely used and has been for years.

Re: pprivilege elevation
by Anonymous Monk on Jan 21, 2003 at 00:31 UTC
    Try writing to a directory which is writeable by the
    CGI user and readable by everyone, then either ask the
    users to just copy the files from point A to point B
    or give each of them a little PERL :-) script that will
    do it for them.

    more than one way to do it

Re: privilege elevation
by BronzeWing (Monk) on Jan 21, 2003 at 03:01 UTC

    Hmm. You said "I don't want to shoehorn all users into the same group and then give the configuration files group priveleges", but perhaps it would be acceptable if you made only the configuration files writable by a certain group, whatever group your CGI is running as (nobody probably). Also I believe you could even sgid that particular CGI into its own group, so that other CGIs wouldn't share its rights to the config files.

    I still agree with the first comment as the most secure, but I know users usually hate being forced to "waste their time" doing "silly little things" like copying config files when you could make their lives so much easier by just turning down the security a little...

    I guess it depends on what balance you want between security and ease of use. :p


Re: Privilege elevation
by joeface (Pilgrim) on Jan 21, 2003 at 20:11 UTC

    If you're running Apache, check out suexec. It allows the "apache" user to execute CGIs that are owned by another user, as if Apache were su-ing to that user just to run the CGI script.

    It requires that you have Apache set up to recognize an html directory for each user (/home/userFoo/public_html, or the like), and a cgi directory for each user. The users can access that directory by going to your URL, but with ~username at the end:

    There are some rather strict requirements for suexec to work. They're listed in the suexec page ref'd above.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://228534]
Approved by dash2
Front-paged by dash2
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2018-05-25 19:28 GMT
Find Nodes?
    Voting Booth?