Thanks for the reply...
It is sftp-server that tries to open /dev/null.
As I dont want to modify sftp-server or anything like that, I think im going
to just populate each chroot environment with a /dev/null. However, as I dont
want /home to have any devices on it, is there a way to have some sort of
file type that simply throws the data away like /dev/null does?
As for the shell, Yep, I am being carefull with it.. all the shell actaully
does, is checks if the arguments given to it is
'-c /usr/libexec/sftp-server', and if it is, it then chroots to the users
home dir, and then it sets effective uid to the uid that called the shell,
and then it executes /usr/libexec/sftp-server. Not much code at all.
I want to research more into possible security hassles ( like /home/foo/.ssh )
and stuff like that later on. Any suggestions in this area? ( security )
Cheers,
Josh
On Thursday 22 June 2006 22:26, Joachim Schipper wrote:
> Well, since nobody else seems to respond...
>
> If you can set it up in a controlled testing environment, you could
> ktrace(1) it. This would tell you, at the very least, what program
> actually opens /dev/null.
>
> A quick grep through /usr/src/usr.bin/ssh suggests that ssh (and, most
> likely, sftp) interacts with /dev/null quite a bit. It might be possible
> to change the code to work without, but that would take quite a bit of
> work I fear.
>
> An alternative hack would be to change sftp directly; in this case, it
> can safely open /dev/null and then call chroot() at the appropriate
> time. OTOH, you have a custom patch that you should apply at the
> appropriate time and place, which, too, has its disadvantages.
>
> Also, be *very* careful in writing the shell, as it must be suid root
> for what you want it to do... this, in fact, suggests that the best
> solution might be to write a trivial shell and just have
> /home/*/dev/null. Or, for that matter, /home/dev/null and chroot into
> /home.
>
> Joachim
