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

[Ensel Sharon]

On Fri, 29 Sep 2006, Paul Hyder wrote:

> For "/home//incoming" there is a chroot to /home followed by a chdir to
> /incoming.  (For "/home" it is a chroot to home followed by a chdir to /)
> You shouldn't need to change the jail or duplicate anything.
> 
> It does make the top level password file more difficult to maintain.
> 
> Should be worth testing, with debuglevel set to 1 to verify that the
> Unison HOME variable is being correctly set.


Ok, this isn't the problem.

The problem is, when I use unison, it sits back errors to me (the remote
user) in the form of:

Fatal error: exception Util.Fatal("Cannot find canonical name of
/home/.unison: unable to cd either to it

And when I add my incoming directory to the users' home directory in the
base systems' /etc/passwd, it says:

Fatal error: exception Util.Fatal("Cannot find canonical name of 
/home//incoming/.unison: unable to cd either to it


See the problem ?  In both cases unison is spitting back to the _remote
user_ the full path leading into the chroot - something that, IMO, they
should never see.

So of course unison can't get to its .unison directory - because it is
trying to put it in /home/home, or /home/home//incoming, respectively.

Let me repeat that in a different way - the remote user is chrooted into
/home, and unison reads the home directory from the base systems
/etc/passwd, and attempts to get there from the chroot - so it ends up
trying to get to /home/home, or from its perspective, /home, which does
not exist in the chroot (since the chroot _is_ /home)

Get it ?

Honestly, at this point, I would be happy if anyone could simply confirm
or deny that unison has ever worked in a scponly chroot in any way.  I
don't think that it does, or has, and I don't think anyone has tried it.