I posted this to comp.infosystems.www.servers.unix earlier, to no
response (that ng seems pretty dead).  At the core, though, this is a
UNIX permissions problem, so, I figured I'd try here as well.  Please
forgive the cross-post and, if this is not the appropriate forum, this
post as well.

Right now I'm mired in a headache...

We have users in their own groups, RedHat style (actually, Fedora).
So, 'joeuser' is in group 'joeuser'.

Apache runs as user apache, group apache.

PHP runs within Apache in SAFE_MODE, which blocks joeuser's scripts
from opening any files not created by joeuser.  However, files created
by these scripts are owned by user apache, and so cannot be read by
the same scripts that created them. :\

The 'websites' directory and subdirectories are mode 770, owned by
user joeuser, group apache.  Files underneath here are mode 660.

Perl scripts run under SuExec, user joeuser, group joeuser, and as
such can only open files owned by joeuser.  PERL scripts can also,
then, open files created by themselves.  However, PERL incurs
additional overhead, and, most people these days seem to be using PHP
(it's taught here, whereas PERL is not, barring the occasional
independent study).

So far so good, right?  Not quite...

ProFTPD insists on owning all files joeuser:joeuser, and I can't
figure out how to override the group value.  I tried setting the GID
bit on ~/websites (owned by group 'apache') and that works one level
down, but any newly created subdirectory (via ftp) is owned by
joeuser:joeuser, and thus inaccessible to Apache...

There's gotta be something obvious I'm missing here.  I can't imagine
all those "shared server" operations are a) totally insecure, or b)
having their users' scripts generate files that can't be opened, or
... ??

Help?  Any good tutorials or books that walk through common
configurations like this?

Thanks!!
Wendell

[ Post a follow-up to this message ]

In article <e77bc23a.0410102346.36e8995e@posting.google.com>,
ojailoop@yahoo.com (Wendell) wrote:

> I posted this to comp.infosystems.www.servers.unix earlier, to no
> response (that ng seems pretty dead).  At the core, though, this is a
> UNIX permissions problem, so, I figured I'd try here as well.  Please
> forgive the cross-post and, if this is not the appropriate forum, this
> post as well.
>
> Right now I'm mired in a headache...
>
> We have users in their own groups, RedHat style (actually, Fedora).
> So, 'joeuser' is in group 'joeuser'.
>
> Apache runs as user apache, group apache.
>
> php runs within Apache in SAFE_MODE, which blocks joeuser's scripts
> from opening any files not created by joeuser.  However, files created
> by these scripts are owned by user apache, and so cannot be read by
> the same scripts that created them. :\
>
> The 'websites' directory and subdirectories are mode 770, owned by
> user joeuser, group apache.  Files underneath here are mode 660.
>
> PERL scripts run under SuExec, user joeuser, group joeuser, and as
> such can only open files owned by joeuser.  PERL scripts can also,
> then, open files created by themselves.  However, PERL incurs
> additional overhead, and, most people these days seem to be using PHP
> (it's taught here, whereas PERL is not, barring the occasional
> independent study).
>
> So far so good, right?  Not quite...
>
> ProFTPD insists on owning all files joeuser:joeuser, and I can't
> figure out how to override the group value.  I tried setting the GID
> bit on ~/websites (owned by group 'apache') and that works one level
> down, but any newly created subdirectory (via ftp) is owned by
> joeuser:joeuser, and thus inaccessible to Apache...

I don't know if Linux has Access Control lists, but on Solaris you can
set up a default ACL on directories so that all files created in that
directory inherit the GID of the directory.  That may not be possible
under your OS.  In which case, you can setup a SUID root script that
correctly sets the group of each directory and file in ~/websites to
apache and run it regularly in cron.

>
> There's gotta be something obvious I'm missing here.  I can't imagine
> all those "shared server" operations are a) totally insecure, or b)
> having their users' scripts generate files that can't be opened, or
> ... ??
>
> Help?  Any good tutorials or books that walk through common
> configurations like this?

You've hit a problem with securing shared multi-user sites.  The web
server must have read access to the pages, so usually UNIX permissions
are 644.  My ISP uses CGIwrap (http://cgiwrap.sourceforge.net/) for perl
scripts but php must run in the context of the browser.

--
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

[ Post a follow-up to this message ]