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:

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 filesystem 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 scp1-compat-srv command. For instructions on chrooting commands, see Chrooting Remote Commands. If you do not need to allow OpenSSH SCP, you can disable all remote commands as described in Disabling Remote Commands.