By default, file access by users is restricted by the file system 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 user name, user's home directory, and the FQDN of the connected client, respectively. The values are read from the environment variables defined in the system.
The following sections give instructions on chrooting the terminal, remote commands, and subsystems.
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 on Linux. 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.
By default, file access by the user using the SFTP subsystem is restricted by the file system access controls. On Unix, access can be further restricted with the usage of the
An example of
chroot usage is shown below:
<services> <rule> <subsystem type="sftp" application="sft-server-g3" action="allow" chroot="/home/%username%" /> ... </rule> ... </services>
%username% will be substituted with the current user name. For a user named
example, the path would be
/home/example. During an SFTP session, the user is now restricted to this directory (and its subdirectories).
Chrooting the SFTP subsystem affects both SFTP and SCP2 operations to the server, but it does NOT affect OpenSSH-style SCP operations. To chroot also OpenSSH SCP, you should chroot the