By default, file access by users is restricted by the filesystem access controls. On Unix, access can be further restricted with the usage of the
chroot attribute. The
chroot attribute can be used with the
chroot attribute must be a directory path. Values
%hostname% will be substituted with the username, user's home directory, and the FQDN of the connected client, respectively.
The following sections give instructions on chrooting the terminal and remote commands. For chrooting with the SFTP subsystem, see Chrooting SFTP (Unix).
An example of chrooting the terminal is shown below:
<services> <rule> <terminal action="allow" chroot="%homedir%" /> ... </rule> ... </services>
When users are restricted to the chrooted environment, they cannot access the normal shell binary. This means that the shell specified in the
/etc/passwd file for the user has to be present in the equivalent place under the chrooted directory. For example, if
/bin/bash as the shell and the user is chrooted to the home directory, a statically linked
%homedir%/bin/bash should exist.
If the user's shell is dynamically linked, you must make sure that the required shared libraries are also in the chrooted environment. You can resolve the dependencies with the
$ ldd /bin/bash libtermcap.so.2 => /lib/libtermcap.so.2 (0x40026000) libdl.so.2 => /lib/libdl.so.2 (0x4002a000) libc.so.6 => /lib/libc.so.6 (0x4002d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) $ ls lib ld-linux.so.2 libc.so.6 libdl.so.2 libtermcap.so.2 libtermcap.so.2.0.8
Also note that shared libraries can have other dependencies:
$ ldd libtermcap.so.2.0.8 libc.so.6 => /lib/libc.so.6 (0x40017000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
The user's environment might also need some other tools, such as:
lsfor listing files
sttyfor setting tty modes
You might also need some device files under the user's virtual root directory. At least A
/dev/null file is needed. You can create it as follows:
$ mkdir dev $ cd dev $ ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Jan 30 2003 /dev/null $ mknod null c 1 3 $ chmod go+w null $ ls -l null
An example of chrooting a remote command is shown below:
<services> <rule> <command application="date" action="allow" chroot="%homedir%" /> ... </rule> ... </services>
Now, the user is restricted to the home directory when running
sshg3 with the remote command
$ sshg3 user@server date
The command to be run has to be statically linked and available under the chrooted environment. In the above example when the user is chrooted to the home directory, a statically linked
date command should exist in
If the command is dynamically linked, you must make sure that the required shared libraries are also in the chrooted environment. See Chrooting Terminal above.