Re: suEXEC or something like it

[Lawrence Statton]

> Hello,
> 
> I am trying to write a set of scripts that will allow multiple users
> to log in via one generic login url (htaccess) and once they are in
> they can use forms to type in a url of a file on the internet, the
> scripts will get that file and put it into their personal webspace on
> the local server and make it available via http://servername/username.
>  I have the login and the $remote_user variable shows their username
> that they loged in with.  I want them to own their home directory for
> security purposes, but if I use getstore, it will only work if the
> directory it is saving too is owned by 'www' .  I have looked into
> suEXEC, but that doesn't seem to fit my needs being that it must be in
> a virtual host or a public_html directory.  Does anyone have any idea
> how I can do this?
> 

First easiest solution: Have you tried playing with groups?  Have the
per-user directories owned by the same group that the webserver runs
as ( I run my apache as apache:apache ) and chmod 664 ... 

Before doing that - run a test LWP program to see if getstore checks
permissions on the target directory itself, or relies on the
underlying filesystem calls to fail?  

Second much more complex, sexy, all-singing/all-dancing solution:
Rather than give Apache permission to write all over (even parts of)
the filesystem, delegate that task to some OTHER script.  (This is
just my personal bias: Any time the webserver has to create a file
somewhere in the file system, I feel I have inadequately designed my
data.)

The CGI program creates a file (or database, if that is your nature)
with a list of files awaiting transfer.  Some OTHER (smaller, more
easily provable correct) process, owned by a more powerful user (or
belonging to a more powerful group) actually does the heavy lifting
with getstore().

Doing it with files (and locking) is Educational, but painful to
test/debug.  Doing it with a database is easier, *IF* you already have
climbed the anthill of setting up a database on the machine.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer  software  consists of  only  two  components: ones  and
zeros, in roughly equal proportions.   All that is required is to
sort them into the correct order.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: suEXEC or something like it

[Lawrence Statton]

> 
> First easiest solution: Have you tried playing with groups?  Have the
> per-user directories owned by the same group that the webserver runs
> as ( I run my apache as apache:apache ) and chmod 664 ... 
> 
> Before doing that - run a test LWP program to see if getstore checks
> permissions on the target directory itself, or relies on the
> underlying filesystem calls to fail?  

Yeah -- I think groups is the easiest way to do it ... here's how I tested.

1)  Create a new user and group to hold the test program 
# useradd -g testuser -c'Test User'  testuser

2)  Create a directory to simulate the per-user directory
# mkdir -p /tmp/users/homer

3) set permissions and ownership on that test directory
# chown homer:testuser /tmp/users/homer
# chmod 775 /tmp/users/homer 

(Note I made a mistake in my earlier email .. 664 is a Bad Idea for
directories .. my bad))

4) Become testuser
# su testuser 
% whoami
testuser
% groups
testuser
% perl /tmp/getstore.pl
200 at getstore.pl line 11.

5) Celebrate success!

. BEGIN PERL PROGRAM ...
#!/usr/bin/perl

use strict;
use warnings;
use LWP::Simple;

use constant URL => 'http://cluon.com/lawrence/index.en.html';

use constant FILE => '/tmp/users/homer/index.html'; 

warn getstore( URL, FILE ) || die "Could not get the file"; 


.. END PERL PROGRAM 

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer  software  consists of  only  two  components: ones  and
zeros, in roughly equal proportions.   All that is required is to
sort them into the correct order.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]