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

[Paul Hyder]

Ok, the comparison of the two helps.  The initial response is that you
are correct, it won't work without a bug fix.

In an earlier message I believe you mentioned applying a Unison patch
for scponly. Am I remembering correctly?  If so can you post the URL
for the specific patch or a copy?

I don't have the platform to test this extensively but the output below
indicates that HOME is being set to homedir instead of chdir_path.  Since
chdir_path isn't a global variable it can't be used to set HOME for Unison.
The 4.6 release code sets HOME to "/" which is equally bad.

You willing to add a few small edits to scponly.c, rebuild, and test it?
(If you did apply a patch the line numbers below are approximate, they are
from the 4.6 release code.)

-move the definition of chdir_path (scponly.c:230)
  char chdir_path[FILENAME_MAX];
 up to be with  homedir and chrootdir (near scponly.c:25 somewhere)

-change scponly.c:600 to be
   if (!mysetenv("HOME",chdir_path))

-change scponly.c:602 to be
   syslog(LOG_ERR, "could not set HOME environment variable to %s (%s)", chdir_path, logstamp());


-change scponly.c:606 to be
   syslog(LOG_DEBUG, "set HOME environment variable to %s (%s)", chdir_path, logstamp());
		
This will ONLY work in a chroot with top level paths that utilize "//" syntax.
(And is of course likely to need additional changes that I'm not seeing yet.
 Anyone on the list have better suggestions?)

If it doesn't work please set debuglevel to 1 and post the syslog output.
	Paul Hyder


Ensel Sharon wrote:

> 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.
> 
> 
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly