Re: Permission conflict between mod_cgi and mod_perl
Jim == Jim Smith [EMAIL PROTECTED] writes: Jim On Mon, Mar 18, 2002 at 02:02:38PM -0800, James Lum wrote: 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?) Jim Should be able to -- mod_perl can run other scripts. mod_perl doesn't run scripts. mod_perl hooks handlers to various stages of Apache processing using an embedded Perl interpreter. One of the modules shipped with mod_perl is called Apache::Registry, which can transform something that looks a lot like a CGI script using CGI.pm into a giant subroutine that then gets hooked as the handler for a particular URL. This is never running the script. It's unfortunate that it's *usually* so transparent, because when it doesn't work, it looks like something is broken. :) Thus, the answer is no - mod_perl cannot run a setuid perl program, unless you mean by forking via fork or system or backticks, which defeats the whole point of mod_perl handlers. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Permission conflict between mod_cgi and mod_perl
On Mon, Mar 25, 2002 at 10:44:10AM -0800, Randal L. Schwartz wrote: Jim == Jim Smith [EMAIL PROTECTED] writes: Jim On Mon, Mar 18, 2002 at 02:02:38PM -0800, James Lum wrote: 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?) Jim Should be able to -- mod_perl can run other scripts. mod_perl doesn't run scripts. mod_perl hooks handlers to various stages of Apache processing using an embedded Perl interpreter. Basically, mod_perl can run scripts in the same manner as any other unix program. mod_perl is just an extension to Apache. I was not in any way implying that mod_perl forked to run Perl code. I was saying that mod_perl can fork if it is asked to. --jim
Re: Permission conflict between mod_cgi and mod_perl
Jim == Jim Smith [EMAIL PROTECTED] writes: Jim Basically, mod_perl can run scripts in the same manner as any other Jim unix program. Maybe we're getting hung up on details, but mod_perl is not a unix program. It's a module for Apache. Therefore, in the same manner is no longer applicable. mod_cgi forks to run processes. mod_perl doesn't fork. mod_perl can run Perl code via the embedded Perl interpreter, and this interpreter can cause a fork. But mod_perl doesn't inherently fork at all. And the distinction is important, especially in the context of this discussion (setuid with mod_perl). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Permission conflict between mod_cgi and mod_perl
[EMAIL PROTECTED] (Randal L. Schwartz) wrote: Jim == Jim Smith [EMAIL PROTECTED] writes: Jim Basically, mod_perl can run scripts in the same manner as any other Jim unix program. Maybe we're getting hung up on details, but mod_perl is not a unix program. It's a module for Apache. Therefore, in the same manner is no longer applicable. mod_cgi forks to run processes. mod_perl doesn't fork. mod_perl can run Perl code via the embedded Perl interpreter, and this interpreter can cause a fork. But mod_perl doesn't inherently fork at all. And the distinction is important, especially in the context of this discussion (setuid with mod_perl). And the sky isn't blue, but the results are the same. mod_perl can't run scripts. Scripts can be run from mod_perl. More than that, set-uid scripts can be run from mod_perl and offer one of the better ways of doing things that require root privileges. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Permission conflict between mod_cgi and mod_perl
At 3:17 PM -0600 3/25/02, James G Smith wrote: And the sky isn't blue, but the results are the same. mod_perl can't run scripts. Scripts can be run from mod_perl. More than that, set-uid scripts can be run from mod_perl and offer one of the better ways of doing things that require root privileges. Oh how I hate to interrupt a good flame war, especially one that Randal is involved in, but wouldn't it be possible to run apache (with mod perl) as set-uid but listening only on 127.0.0.1:81. They just establish a proxy connection to the backend setuid apache? Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Permission conflict between mod_cgi and mod_perl
On Mon, 25 Mar 2002 15:17:06 -0600, James G Smith [EMAIL PROTECTED] said: JS And the sky isn't blue, but the results are the same. JS mod_perl can't run scripts. JS Scripts can be run from mod_perl. JS More than that, set-uid scripts can be run from mod_perl and offer JS one of the better ways of doing things that require root privileges. Results are not same. Basically Apache::Registry (handler used with mod_perl to emulate execution of scripts) just opens file which contains script, evals it as big subroutine and calls that subroutine. Opening and reading set-uid file which contains script doesn't give automagically root rights to instance of apache process which handles request. -- oIlya Martynov = http://martynov.org/o oTIV.net = http://tiv.net/ o
Re: Permission conflict between mod_cgi and mod_perl
Ilya Martynov [EMAIL PROTECTED] wrote: On Mon, 25 Mar 2002 15:17:06 -0600, James G Smith [EMAIL PROTECTED] said: JS And the sky isn't blue, but the results are the same. JS mod_perl can't run scripts. JS Scripts can be run from mod_perl. JS More than that, set-uid scripts can be run from mod_perl and offer JS one of the better ways of doing things that require root privileges. Results are not same. Basically Apache::Registry (handler used with mod_perl to emulate execution of scripts) just opens file which contains script, evals it as big subroutine and calls that subroutine. Opening and reading set-uid file which contains script doesn't give automagically root rights to instance of apache process which handles request. I never said anything about Apache::Registry. If you are using a Perl interpreter with mod_perl, then you can fork and run a suid script. That's what I'm trying to say. Nothing more, nothing less. End of story. Even the Eagle book speaks of running scripts (though in the context of Apache::Registry), so using that terminology is not original with me. I was trying to talk about something in a manner that might be somewhat understandable, but people started pointing out the trees and ignoring the forest. I will say no more on this subject. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Permission conflict between mod_cgi and mod_perl
Folks, 1st, I want to thank you all for your responses and clarifications about 'suid perl' and 'mod_perl' and the way they work together. It is kinda like I suspected. :( 2nd, I should have worded my real question a little differently. Basically, it is: How can I get perl code, invoked by the Apache web server, to: 1. create/write/read files that have the ownership of the owner of the perl code. (Apache suexec) 2. execute with the best performance. (mod_perl) Since Apache suexec and mod_perl do not work together, my alternatives are: 1. - Configure Apache WITHOUT suexec and WITH mod_perl. - Invoke 'suid perl' for the perl program. - Have the 'suid perl' program be owned by a non-root userid which is the owner of the program. - Convert the 'suid perl' program to meet mod_perl requirements. OR 2. - Run a separate Apache web server that supports only a single domain or userid. - Run the separate Apache web server with a userid that is the same as the owner of the perl script. - Configure the separate Apache server WITH mod_perl and WITHOUT suexec. (suexec is not needed) - mod_perl the perl program. OR 3. - Lobby to get Apache suexec and mod_perl to work together. OR 4. - Which choice gives me the best of all worlds? the world in which: - a user's cgi program can create/write files that are owned by the owner of the cgi program - and has the performance of compiled code - and does not complicate or slow down the web server - and does not use too much of the system resources - and is not overly complicated for the programmer - and is not overly complicated for the web admin I don't want much ... do I ;=) jim Randal L. Schwartz wrote: Jim == Jim Smith [EMAIL PROTECTED] writes: Jim Basically, mod_perl can run scripts in the same manner as any other Jim unix program. Maybe we're getting hung up on details, but mod_perl is not a unix program. It's a module for Apache. Therefore, in the same manner is no longer applicable. mod_cgi forks to run processes. mod_perl doesn't fork. mod_perl can run Perl code via the embedded Perl interpreter, and this interpreter can cause a fork. But mod_perl doesn't inherently fork at all. And the distinction is important, especially in the context of this discussion (setuid with mod_perl). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Permission conflict between mod_cgi and mod_perl
James Lum wrote: Folks, 1st, I want to thank you all for your responses and clarifications about 'suid perl' and 'mod_perl' and the way they work together. It is kinda like I suspected. :( Also refer to http://perl.apache.org/guide/multiuser.html#ISPs_providing_mod_perl_services -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
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
On Mon, 18 Mar 2002 14:17:35 EST [EMAIL PROTECTED] wrote: 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? 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. :) - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
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: Permission conflict between mod_cgi and mod_perl
At 3:42 PM -0500 3/18/02, [EMAIL PROTECTED] wrote: 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 !!) To change default file permissions of newly created files perldoc -f umask To change ownership of a file without a fork* perldoc -f chown To change permissions of a file without a fork* perldoc -f chmod To create directories without a fork* perldoc -f mkdir * on most *nix based systems Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Permission conflict between mod_cgi and mod_perl
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?) 2. run the web server as root ... DO NOT DO THIS! ... it will cause security problems. 3. use apache suexec and set root as the owner of your cgi program, but modperl and suexec do not work together. :( your best bet for what you want to do is to use suid perl ... but it would sure be nice if suexec and modperl worked together ... especially since most cgi programs need to save data for the userid of the cgi program ... especially when virtual hosts are supported ... and shopping cart cgi programs need to save all kinds of tracking data. in any of the above alternatives, be nice to your sys admin, since root access is needed. jim Frank Wiles wrote: On Mon, 18 Mar 2002 14:17:35 EST [EMAIL PROTECTED] wrote: 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? 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. :) - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
