[scponly] Limiting to home directory without chroot?

[Kaleb Pederson]

On Friday 30 September 2005 10:21 am, scponly-7264 at tagged.lorens.org wrote:
> On Fri, Sep 30, 2005 at 09:44:13AM -0700, Kaleb Pederson wrote:
[snip]
> > Can you explain why it won't work for you?  It works for many of us, so
> > unless there are special conditions that you need to meet, it will
> > probably work.
>
> It's a web server, and the accounts are used as web sites. Apache runs
> as its own user and thus needs o+rX to read pages, but one student
> shouldn't be able to read another's PHP. Putting all files into the apache
> group, but not the users, would solve that problem, but then I have to find
> a way to make sure that files have the correct group on upload.

Ok.  I would suggest you setup a default ACE that makes sure apache has full 
read access to it, then you can ignore the group ownership.  You could also 
use setgid folders to make sure that the group is set to the group in 
question when any files/folders are created.  Personally, I use the apache 
ACE option because then I can have groups of users working in the same file 
hierarchy yet allow apache to read the files without making the files 
readable to others.  (BTW, we use scponly for, among other things, exactly 
the purpose you mentioned).

Here's a sample using ACEs:

$ getfacl cmshelp
# file: cmshelp
# owner: root
# group: cmshelp
user::rwx
user:apache:r-x
group::rwx
mask::rwx
other::---
default:user::rwx
default:user:apache:r-x
default:group::rwx
default:mask::rwx
default:other::r-x

You might want that last entry to be --- instead of r-x.

You will also have to make sure you are using safe_mode to make sure that they 
can't use PHP directly to read somebody else's files.  [E-mail me directly if 
you have questions in this area as this is getting fairly off-topic].

What I ended up with was something like this /var/www (a chroot). 
And /var/www/home/<username>.  By setting /var/www/home to perms 661, the 
users can't look at other users' home directories.

> Maybe change everything and make apache run as each user, haven't
> thought about it, but it seems a much greater change than just adding
> "secure upload your files".

I don't think there is a good way to do this.  You would have to use 
mod_suexec or something, but then you would have to have the php cgi 
interpreter (or maybe a symlink to it (don't think that's allowed) in each 
directory... per mod_suexec).  It could be done... but would be difficult to 
do right.

> > Scponly isn't a server, it's a pseudo-shell.  All it does is [optionally]
> > chroot the users to a directory and place them in a directory where they
> > have access.  Depending on permissions and configure options, it then
> > allows them to execute only limited commands, possible only sftp.
> >
> > Scponly doesn't do the forbidding, sftp or the other command must do the
> > forbidding.  In certain cases, sftp might not allow them to execute the
> > cd command at all (for example, if only sftp access is allowed).
>
> Limiting scponly users to sftp only is definitely an option. So
> I should look at tweaking the sftp subsystem? It's not cd itself
> that I want to forbid, just cd above home dir. If sftp can do
> that, then perfect.

We do that with all our web users.  They each have only sftp access to the 
server.

> > There is FTP over SSL which several unix clients/servers support, as well
> > as some commercial windows ones.  Google is your friend.
>
> Yes :-) I'd like it to work with as many windows clients as
> possible, but as it's just setting up I'm not afraid of calls
> saying "it worked with XXXXXXX before!!!!!" :-)

Hehe.. and that's exactly what we did!  And the last couple versions of 
dreamweaver supports SFTP as well... so it has minimal impact on most users.

So... sftponly should do everything you need once fully understood.

Let me know if you still have questions.

--Kaleb

> Thanks!
>
>
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20050930/4fdbedc9/attachment.bin