Fwd: Permission conflict between mod_cgi and mod_perl
Forgot to cc the list ... ---BeginMessage--- In a message dated 18-Mar-02 10:14:50 PM GMT Standard Time, [EMAIL PROTECTED] writes: To change set the default /etc/skel files and to use useradd on linux, you need to run as root ... but the cgi code normally runs with the userid of the web server (nobody or www) and thus cannot successfully invoke the useradd command. To successfully invoke the useradd command, you could do one of the following: 1. use suid perl and set the owner as root ... but i do not know if you can run a suid perl program under modperl. (anyone? will this work?) I think this is roughly my original question ... I didn't find a defininitive answer in the guide or several google searches. And I was fairly sure that the eagle book didn't cover it ... I've heavily used the egale book since the start of this project since it's my first foray into the world of true mod_perl ... and I don't remember seeing anything like this in there. 2. run the web server as root ... DO NOT DO THIS! ... it will cause security problems. Part of my concert is that we're going to have a security audit of our program after some inital beta testing. I know I'm faulty where security is concerened and I'm starting to try and lock down the obvious holes ... like having 777 files. Lord knows I don't want to have the server running as root on top of this. 3. use apache suexec and set root as the owner of your cgi program, but modperl and suexec do not work together. :( Exactly and the goal is to eventually be totall mod_perl ... as soon as I get a chance to figure out a clean path around the expat issues, some how I can't see telling clients they need to re-compile apache as a solution, I think they'd see not purchasing our product as a solution. in any of the above alternatives, be nice to your sys admin, since root access is needed Heh ... I am the sysadmin ... or at least in this rare instance I have the same effective control over the box. Thanks for the suggestions but as I said adding new users to the box isn't the solution I was hoping for ... and it seems to be fraught with all of the same problems I'm currently having ... -Chris ---End Message---
Permission conflict between mod_cgi and mod_perl
Hi, We have a product that at the moment uses a combination of CGI and mod_perl. While in the future it will be totally ported to mod_perl, until we figure out exactly how we'd like to overcome the 'expat' issues we're stuck with a mixed-mode enviroment. Here however is the current problem. The cgi script under a specific set of circumstances (signing up a new account) copies a directory using a fork to the system's cp command and they're created as user: apache group: apache. I'm not by nature a linux mod_perl programmer and thus I'm not totally up on the nuances of what I'm doing here. I needed a quick solution to copying a template directory to a user directory when a new user account was created, and since it happened only once during the user's process I figured a fork to cp was worth the performance hit for the simplicity it provided. Single line of code vs some directory recurison scheme. The problem is when I later try access the files or directories under either mod_perl or the cgi process the server returns an error unless I set the chmod to 777 on the files. This is obviously not good. I have done some looking into using $ before I write the file but I hadn't found anything about using this under mod_perl ... let alone mod_cgi ... except that generally it's a bad idea to setuid to root. um yeah ... I wasn't gonna do that ... I just didn't want to give the world 777 access to files that run under apache:apache. I also didn't want to follow bad with worse implimenetation wise. Is there a simple secure method for copying a directory from a template directory to a user directory and then giving access to the (new) user directory? Any other considerations here? Thanks -Chris ::who will be happy if someone even says Go Read the Nautilis book ... it covers Recursion in depth::
Re: Permission conflict between mod_cgi and mod_perl
In a message dated 18-Mar-02 7:36:55 PM GMT Standard Time, [EMAIL PROTECTED] writes: You may want to look into useradd and /etc/skel on a Linux system. It has everything you are trying to accomplish handled automatically by using the standard Linux user creation techniques. No need to re-implement the wheel. :) That's just it ... we didn't want to have to create whole new user accounts for everybody. Just a small directory of files for a demo of our web-app. I'd be happy if all the apps weren't apache:apache ... but I was thinking there had to be a better solution than `chown nobody:nobody $directory -R` (just an example !!) I will take a look though at /etc/skel ... I hadn't heard of it. -Chris
Re: New mod_perl Logo
In a message dated 30-Jan-02 6:08:29 AM GMT Standard Time, [EMAIL PROTECTED] writes: All these American-style names are verging on the racist. This is world-wide code, not f---ing American-wide code. Don't let the crappy AOL account fool you. Nessie is about 3 hours from here. The Yetti I believe is indiginous to Asia isn't it? And as for australian beasties ... I just couldn't think of any off the top of my head ... . -Chris [EMAIL PROTECTED]
Re: New mod_perl Logo
In a message dated 30-Jan-02 12:50:50 AM GMT Standard Time, [EMAIL PROTECTED] writes: How about "BigFoot"? Probably not the best for a server application. Might make one think of the "footprint" involved ... and isn't one of the major reasons to moving to mod_perl to reduce the overhead and "footprint" of the server? Now Yetti no conotation there. Or Swamp Beast, Sasquatch, or possibly even the local favorite Nessie (I'd love to see Ora get a picture of her on the next book!) -Chris
Adding information to Virtual Hosts in a startup file...
Hi,
I'd like to add a location directives dynamically at startup to a VirtualHost using a
startup script.
I've been trying:
$Apache::ReadConfig::VirtualHost{'127.0.0.1:80'}-{Location}-{'/'} = {
SetHandler = 'perl-script',
PerlHandler = 'Apache::Hello',
};
which doesn't work ... while
$Apache::ReadConfig::Location{'/'} = {
SetHandler = 'perl-script',
PerlHandler = 'Apache::Hello',
};
works but clobbers other information already stored in other VirtualHosts. I
specifically need to patch into one virtual host out of possibly many.
The configuration of the various machines is out of my control which is why I was
going with the Apache::ReadConfig approach.
Thanks
-Chris
