# Big chroot jail question

## owenm

I am fooling around with a jail. I have /chroot set up, with all files owned by chroot:nobody.

I cannot chroot with my chroot user  :Sad: 

"chroot: cannot change root directory to /chroot: Operation not permitted"

I have entered the users name into /etc/security/chroot.conf but had no luck.

 I got it to work by suid 0 on the chroot binary, but I have an intense dislike towards +s on files... It Just Isn't Good  :Wink:  [as a SGI IRIX user, I can recall the many times they screwed up with suid and don't want to see this!]

How can I get my normal user to chroot into the jail without special abilities?

----------

## CheshireCat

I believe the chroot call can only be made by root, so there's probably no way to let a normal user chroot without making chroot suid 0.  If anybody could use chroot, /etc/security/chroot.conf would be pointless, because users could compile their own chroot binary that didn't check before actually calling chroot.

----------

## owenm

 *CheshireCat wrote:*   

> I believe the chroot call can only be made by root, so there's probably no way to let a normal user chroot without making chroot suid 0.  If anybody could use chroot, /etc/security/chroot.conf would be pointless, because users could compile their own chroot binary that didn't check before actually calling chroot.

 

hmmph, but this reduces the security as you enter the jail uid 0!

so do i need a wrapper that takes root, does the stuff, and then releases it? what would be best here?

----------

## CheshireCat

Btw, just checked the man page for the chroot function, it confirms that only root can use it.  I wrote a wrapper script for mldonkey (before there was a nice init file for it in portage), which started it in a chroot jail.  I'd suggest using perl or Python for this purpose (I used Python), because they provide wrappers to the setuid function, allowing you to drop root privileges without needing a binary for su or setuidgid.  If you already have a complete environment in your jail, you could use a shell script and just use setuidgid after chroot.

----------

## CMI

Since /etc/security/chroot.conf exists I'd assume its possible to grant individual users those rights however traditionaly only root can chroot and its dangerous to have suid root chroot. chroots can be broken out of if your root (beacuse you can chroot again) so in that case whats the point?

Thinking of a mailing lost post I read eairlier I must say that if this were OpenBSD, "man chroot.conf" would work. Maybe someone will come up with an anwser for you but keep playing around with that.

----------

## CheshireCat

There is not way for an unprivileged user to chroot without a setuid utility.  The protection against non-root use isn't in the chroot utility, it's in the system call used to perform the chroot operation, which will fail if called by a non-root user.

I had trouble finding good documentation for /etc/security/chroot.conf, but it looks like it has nothing to do with the chroot program at all - it appears to be connected to a PAM module for chrooting a particular account at login.

I would suggest that if this is not what you need, you write a simple wrapper script to run as root, which will chroot and then change to the appropriate user.  Here's the one I use for chrooted mldonkey:

```
#!/usr/bin/python

import os, sys

MLDONKEY_HOME='/home/mldonkey'

MLDONKEY_EXE='/mlnet'

MLDONKEY_UID=999

MLDONKEY_GID=999

MLDONKEY_NICE=18

if os.fork():

        sys.exit()

os.close(sys.stdout.fileno())

os.close(sys.stderr.fileno())

sys.stdout.close()

sys.stderr.close()

sys.stdout = file('/dev/null','w')

sys.stderr = file('/dev/null','w')

os.nice(MLDONKEY_NICE)

os.chdir(MLDONKEY_HOME)

os.chroot(MLDONKEY_HOME)

os.setgroups([])

os.setregid(MLDONKEY_UID,MLDONKEY_UID)

os.setreuid(MLDONKEY_GID,MLDONKEY_GID)

os.setsid()

os.execl(MLDONKEY_EXE,MLDONKEY_EXE)
```

----------

