openssh unix dev - Jun 2012 - While using internal sftp server, need to access files outside chroot

Hi,

I need to make a custom code change in sftp-server module to copy the received
file outside the chroot-setup.  I am trying to chroot repeatedly to get physical
root directory and the copy received file to a directory outside chrooted
directory.

The children processes are owned by the sftp-user and so, sftp child process
does not have permission to escape out of chroot.

Is there a simple way where I can spawn child processes for sftp so that these
processes are owned by root.

I tried to change user to root, but user root is not defined in chroot
environment and so, setting setuid and becoming root to chroot is not an option.

Thanks,
Raghu

On 07/06/12 18:40, Raghu Udupa wrote:
> Hi,
>
> I need to make a custom code change in sftp-server module to copy the
received file outside the chroot-setup.  I am trying to chroot repeatedly to get
physical root directory and the copy received file to a directory outside
chrooted directory.
>
> The children processes are owned by the sftp-user and so, sftp child
process does not have permission to escape out of chroot.
Heh, that's precisely the point of placing it in a chroot.
> Is there a simple way where I can spawn child processes for sftp so that
these processes are owned by root.
>
> I tried to change user to root, but user root is not defined in chroot
environment and so, setting setuid and becoming root to chroot is not an option.
>
> Thanks,
> Raghu
It doesn't matter. You can make a binary setuid from outside the chroot.
When you run it from the inside, it will become root, even if there's no
"user named root" inside. You can then use the classical technique to
exit a chroot(), and copy the file you wanted, *being very careful*, as
that script will be a weak point in your security (you don't want to
allow it to copy files anywhere, or to overwrite configuration files,
for instance).

Some reasons this might not work include that the mount doesn't allow
setuid, and that your kernel is security-enhanced to avoid chroot-escaping.