aCC has asked for the wisdom of the Perl Monks concerning the following question:

Hi.

I wrote a cgi-script that can administer users on a machine (mainly for setting up virtual domains etc. and still being compatible to all normal email/pop/imap/www/"you-name-it" servers). But obviously to create/delete/add a user, I need root permissions, which Apache doesn't like at all.

I have one quick-and-dirty setup that uses "sudo" to get the higher permissions while not sacrificing the whole system.
But I am not happy with that setup.

How can I do a cleaner implementation of this??

Replies are listed 'Best First'.
RE: CGI and root permissions
by dempa (Friar) on May 29, 2000 at 16:01 UTC
    We frequently use a method were the CGI script writes to a batchqueue. This queue is periodically read by a script, running from cron (root's crontab). Maybe not the best solution, but it works.
[reply]
Re: CGI and root permissions
by Maclir (Curate) on May 30, 2000 at 01:36 UTC
    We have a script here that is used to change NIS+ passwords. There are still a few bugs in it, but the rules are:
    1. Script is owned by root, and suid.
    2. Use the -T (taint option).
    3. This only runs on our intranet.
    4. Use the -T (taint option).
    5. Test, test and test again.
    6. Use the -T (taint option).
    7. When you think it works properly with no unwanted side effects, give it to your most troublesome "wanna be a programmer" to test.
    If anyone is interested, email me at:
    rayk@transport.nsw.gov.au
    for a copy.

    Ken

[reply]
Re: CGI and root permissions
by perlcgi (Hermit) on May 29, 2000 at 16:18 UTC
    Lincoln Stein has a module user_manage: The All-Purpose Web Server User Management Script.
    I have not used it!
    In the docs Lincoln suggests how in order for the script to be able to update password and group files, not only must it have write access to the files themselves, but to the directory that contains them (the script creates lock and other temporary files within the directory). He suggests three alternatives
    1. Run as a SUID Script
    2. Run as a SGID Script
    3. The scary option - Keep the Password and Group Files in a Directory writable by "nobody".

    Maybe the solution you have is not so bad after all?
[reply]
      Unfortunately the README of that module says:

      Don't Use This Script to Change /etc/passwd or /etc/group !!

      The file formats are different. You will destroy your system if you try it.

      The Script Doesn't Handle NIS, POP or System Passwords

      It's designed for updating passwords on the Web only. If you want to allow users to change their POP, NIS or system passwords via a Web interface, you're going to have to roll your own.

[reply]
Re: CGI and root permissions
by Michalis (Pilgrim) on May 30, 2000 at 00:38 UTC
    Well, I've written a project named WebRat (http://webrat.hellug.gr) which actually does several scary things on every host it's installed, like adding/removing/modifying users (among others). It isn't the prettiest thing, nor the cleanest code, but it was written for a purpose in that way.

    Any way, to cut the long story short, I create a server, which is executed by the root user, it only listens to 127.0.0.1 and then the cgi opens a connection to the server (and localhost of course) and passes in there the request.

    The request parsing, security checks etc are done on the CGI, while all the real stuff (like open /etc/passwd, write and save) are performed by the server.

    If that doesn't make sense as I present it (sorry about my english by the way :-) , just grab the source and get a look. I think it's a nice approach for that kind of stuff.

[reply]
Re: CGI and root permissions
by lhoward (Vicar) on May 30, 2000 at 01:30 UTC
    This won't help you today, but O'Reilly is publishing Perl for System Administration in July of 2000. According to the O'Reilly site one of the chapters is going to be on user adminstration.
[reply]
      This will probably not help either, but Cobalt's RaQ systems have a web interfase that allow to create/modify users, ifconfig, httpd.conf, and reboot the box. They use perl (for the GUI at least).

      I think they run a different httpd, on port 81, maybe with a different configuration.

[reply]

Back to Seekers of Perl Wisdom