[scponly] won't someone _please_ think of the archives ? (scponly + unison + chroot)

[Kaleb Pederson]

On Wednesday 04 October 2006 8:05 am, Ensel Sharon wrote:
> Well, perhaps this is my fault then.
>
> My setup is simple - everyone has the same home directory:
>
> /home
>
> And that is in _both_ the root /etc/passwd and the chroot /etc/passwd
>
> And inside of /home are a bunch of "incoming" directories, one per user -
> the user has no right (except traversal) to /home, and has no rights at
> all to any of the incoming dirs except their own.

Hmm.. You're trying to accomplish the same thing that I have setup (if I 
understand everything correctly).

I have the following users setup:

user1
user2
user3

In /etc/passwd (outside of chroot), I set the following home directories 
(ordered respectively):

/home/chroot//home/user1
/home/chroot//home/user2
/home/chroot//home/user3

Thus, scponly chroots to /home/chroot for all of the above users.

/home/chroot/home has restrictive permissions on it: 711

And /home/chroot/etc/passwd (ie. /etc/passwd within the chroot) looks like the 
following:

/home/user1
/home/user2
/home/user3

It sounds like my /home/userN directories are the equivalent of 
your "incoming" directories.

Every program that launches from within the chroot seets /home/userN as a 
regular home directory.  It known nothing about the chroot -- nor does it 
need to.

Is there a particular reason the "incoming" directory isn't the home directory 
of your user? I could understand if everybody were using the same incoming 
directory, but that doesn't sound like your case.

> This allows me to maintain only a single chroot skeleton (/etc,/bin,/usr
> and so on)  Further, this has worked great - no problems with any ssh apps
> (except unison).

It seems strange that most of them would work, but I'm not sure what they 
require.  Did you happen to compile with --with-default-chdir ? It doesn't 
sound like you did but I want to confirm nonetheless.

The solution I mention above also uses only a single chroot.  It gets costly 
with many users to use individual chroots for all the users.

> BUT, you are correct - both /etc/passwd and (chroot)/etc/passwd contain
> the same thing:  /home   for everyones home directory.
>
> What would you put in its place ?

See the above.  I have a cron script that I run that adds missing users to 
the /etc/passwd within the chroot with the corrected path information.

> (honestly I just thought the home-dir field in the chroot/etc/passwd was
> just a placeholder and didnt matter - which was somewhat justified given
> that it has worked wonderfully, until unison)

It's not just a place holder.  Every program can use the information present 
in it or not, so it's not surprising that some programs work and some don't.

> (are you sure Paul Hyder wasn't correct and that my setup is ok, and there
> is just a bug related to unison ?)

No. Paul sent me an e-mail with a bit more information.  It sounds like unison 
might be using the HOME environment variable. If that is indeed the case -- 
unison won't work within the chroot (given that it's hard coded to '/').

After looking at Paul's comments and taking a look at the code in this area 
(which I hadn't yet done). I'm guessing that we're both right.

I think Paul understands (and understood before I did) the problem that you 
are having right now -- and is correct.  His patch sounds appropriate.

However, I think that once you applied his patch you would find that unison 
would be trying to write to '/home' instead of '/'.  So... in taking a better 
look, I think changing /etc/passwd inside and outside the chroot based on the 
model that I outlined above will allow it to work once Paul's patch has been 
applied (and noting that it might require a couple more tweaks).

Hopefully that makes sense.

--Kaleb
-------------- 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/20061005/83d870f3/attachment.bin