[scponly] Suggestion for home dir in jail

[Kaleb Pederson]

On Wednesday 01 August 2007, Graham Toal wrote:
> If I understand this right, the way to set the default home directory
> for a chrooted user such as scponly is to set the home dir in the
> external password file to something like  "/home/scponly//home/scponly".

Correct.

> Two suggestions; 1) Quick hack:  if there's no "//" in the string, use
> the whole string as the chrooted home dir, *not* "/".  By making it "/",
> you break the expected behaviour of commands like
> "scp file scponly at host.com:" as it tries to write it to / rather than the
> user's home dir.  That way you just need to duplicate the same home
> directory naming convention (eg /home/scponly) inside the jail.

I don't think the current behavior is intuitive, but I also don't think it's 
intuitive to require that the same hierarchy be replicated within the chroot, 
although perhaps that's the general structure many admins follow.

I don't think I would change it just because it will break it for users who 
now expect it to work that way (and have configured their systems to work 
with it), although your point is certainly valid.

> or 2) Less quick hack: once chrooted, re-read /etc/passwd and get the
> *internal* home dir from the dummy password file.  This is the more
> general and useful solution, and it behaves the way you would expect.

Although that would change existing behavior, that seems like a reasonable 
idea.  Right now, we don't make any file calls directly, but rather let the 
system calls handle it, so I would need to find out if the necessary pieces 
are in place in the chroot to continue to use the system calls rather than 
trying to parse /etc/passwd manually.

Overall, I'm not sure that's better than having the /etc/passwd file (outside 
the chroot) setup correctly in the first place.  Once it's setup correctly, 
`scp myfile user at host:` behaves correctly.  This also requires less 
dependencies and has a shorter code path -- which helps reduce the chance for 
errors.  I guess I lean toward leaving it the way it is and making sure it's 
documented... but perhaps one of the other developers feels differently?

I'm planning on cleaning up the instructions a bit for the next release, so 
hopefully everything will be a little more clear then.

> I have one related question - in the spirit of unix and having one
> tool do one thing well, isn't there some jail package somewhere
> that could do all the jailing work, which you could just use rather
> than building it in to scponly?

That's also a good suggestion.  I'm not sure which one we would use either, 
but I know there are a number of good ones out there. 

Right now there are definitely problems with the chroot setup.  I had a lot of 
manual changes to make during my last OpenBSD install, but generally the 
Linux install has worked out-of-the-box for me.

> PS the problem in the thread "segfault when trying to connect" is most
> likely a file or directory missing in the chroot environment, and some
> part of the code not checking a return code or file handle for the error.

Perhaps, but if I read through the last error output correctly it's dieing in 
some basic string operations, which shouldn't happen unless something isn't 
null terminated that should be.  Hopefully we'll find out soon.

> I hit it several times while working out from scratch by trial and error
> which files were all necessary to make scponlyc work under
> SuSE.

If you could document as much of this as possible that would be great -- I 
know sometimes it's not possible (due to time constraints, etc.), but it 
really helps.

Thanks for the great feedback and suggestions.

--Kaleb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20070801/d581deb6/attachment.bin