On Sun, Mar 02, 2003 at 12:26:40PM -0500, Bob Rogers wrote: > From: John Tobey <[EMAIL PROTECTED]> > Date: Sun, 2 Mar 2003 10:42:29 -0500 > > The clean and safe solution would be to run your own copy of the web > server (if allowed) or configure the existing server for "suExec" (if > supported). > > Hmm. I don't see how a running server process would change EUID from > the unpriviledged "nobody" user without having a password stored > somewhere, readable either to user "nobody" or group "www". In which > case you are giving away more than just database access to anyone who > shares the server.
I am assuming that Joel has his own shell account and cgi-bin directory, but the web server is configured to run all CGIs as the web server UID(+EUID+GID...). This setup is an endless source of pain for security-conscious users, and it results in a lot of "chmod 666" to get things done. A proper setup would use Apache's suEXEC feature (http://httpd.apache.org/docs/suexec.html) and run CGIs as the owner of the cgi-bin, in this case Joel's account. I assume that it was not set up this way simply out of laziness, because configuring suEXEC takes some Unix security knowledge a half hour of concentrated effort the first time. Maybe cgiwrap is an adequate substitute for suEXEC, I haven't used cgiwrap and can't comment. > A minimal solution would be to write a setuid "helper" program (not a > script) that just changes EUID, copies to stdout a specially-protected > password file (the name of which is built into the binary), and exits. > The CGI script itself can then run under normal privilege (which is much > safer), executing this program when it needs the DB credentials. But > there's a catch: You would still need to figure out a way to ensure > that only *you* can run the helper program. I'd bet that if you have to > start from a shared user ID, there's simply no way to do this. You > would have to present credentials of some sort to the helper program in > order to tell it to give you your DB credentials, but you'd still > couldn't keep your helper credentials secret from other shared users. Yup, this kind of minimalism is smart if you are ever forced to deal directly with setuid. > And the sysadmin might not be willing to create a unique UID for you in > the first place, in which case (I believe) no solution is possible, and > you are back to square one. Again. As I understand, Joel already has this kind of unique UID. > In a nutshell, I use the PostgreSQL "ident" authentication feature, > and restrict access to the DB server to connections coming from the > loopback address. This has the distinct advantage of making a password > unnecessary: Since the DB server can securely and reliably query the > name of the user who makes the incoming connection, each user must first > prove who they are to the OS's satisfaction, and then the DB server can > confidently grant access to that DB user account, and no other. But the name of the user is "www" and is not a trusted account, since other users can write code that runs as www too. Only the script ownership is trustworthy. Best. -John _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
