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 subsystem
,
terminal
, and command
elements.
The chroot
attribute must be a directory path. Values
%username%
, %homedir%
, and %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 /etc/passwd
lists /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
command:
$ 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:
ls
for listing files
stty
for 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 date
:
$ 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
%homedir%/bin
.
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
chroot
attribute.
An example of chroot
usage is shown below:
<services> <rule> <subsystem type="sftp" application="sft-server-g3" action="allow" chroot="/home/%username%" /> ... </rule> ... </services>
Here %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).
Note | |
---|---|
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 |