Privilege elevation

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?

Comment on Privilege elevation
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. -bl0rf more than one way to do it	[reply]
Re^2: pprivilege elevation by diotalevi (Canon) on Jan 21, 2003 at 01:34 UTC
Huzzah! In fact - you could put this into a cron job and it'd happen automatically for your users. Seeking Green geeks in Minnesota	[reply]
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 -BronzeWing	[reply]
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.	[reply]
Re: Privilege elevation by joeface (Monk) 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: http://www.yourdomain.com/~userFoo/cgi-bin/saConfig.cgi There are some rather strict requirements for suexec to work. They're listed in the suexec page ref'd above. Cheers, Joe	[reply]


go ahead... be a heretic
	PerlMonks

Privilege elevation

The best material for plates (tableware) is: