--- name: "schroot.conf" section: "5" platform: "linux" package: "schroot" version: "1.6.13-11" release: "Arch Linux 2026-11-01" platforms: ["linux"] url: "https://new.carta.tech/schroot.conf" --- # schroot.conf(5) chroot definition file for schroot ## NAME schroot.conf - chroot definition file for schroot ## DESCRIPTION ***schroot.conf*** is a plain UTF-8 text file, describing the chroots available for use with schroot. Comments are introduced following a ‘`#`’ (“hash”) character at the beginning of a line, or following any other text. All text right of the ‘`#`’ is treated as a comment. The configuration format is an INI-style format, split into groups of key-value pairs separated by section names in square brackets. ### General options A chroot is defined as a group of key-value pairs, which is started by a name in square brackets on a line by itself. The file may contain multiple groups which therefore define multiple chroots. A chroot definition is started by the name of the chroot in square brackets. For example, - `[sid]` `The name is subject to certain naming restrictions. For further details, see` `the section “`*Chroot Names*`” below.` `This is then followed by several key-value pairs, one per line:` - ***type=****type* `The type of the chroot. Valid types are ‘plain’, ‘directory’,` `‘file’, ‘loopback’, ‘block-device’,` `‘btrfs-snapshot’, ‘zfs-snapshot’ and ‘lvm-snapshot’. If empty or omitted,` `the default type is ‘plain’. Note that ‘plain’ chroots do not` `run setup scripts and mount filesystems; ‘directory’ is recommended for` `normal use (see “`*Plain and directory chroots*`”, below).` - ***description=****description* `A short description of the chroot. This may be localised for different` `languages; see the section “`*Localisation*`” below.` - ***priority=****number* `Set the priority of a chroot. `*number*` is a positive integer indicating` `whether a distribution is older than another. For example, “oldstable”` `and “oldstable-security” might be ‘0’, while “stable”` `and “stable-security” are ‘1’, “testing” is ‘2’` `and “unstable” is ‘3’. The values are not important, but the` `difference between them is. This option is deprecated and no longer used by` `schroot, but is still permitted to be used; it will be obsoleted and removed in` `a future release.` - ***message-verbosity=****verbosity* `Set the verbosity of messages printed by schroot when setting up, running` `commands and cleaning up the chroot. Valid settings are ‘quiet’` `(suppress most messages), ‘normal’ (the default) and ‘verbose’` `(show all messages). This setting is overridden by the options `*--quiet* `and `*--verbose*`.` - ***users=****user1,user2,...* `A comma-separated list of users which are allowed access to the chroot. If` `empty or omitted, no users will be allowed access (unless a group they belong` `to is also specified in `*groups*`).` - ***groups=****group1,group2,...* `A comma-separated list of groups which are allowed access to the chroot. If` `empty or omitted, no groups of users will be allowed access.` - ***root-users=****user1,user2,...* `A comma-separated list of users which are allowed `**password-less**` root` `access to the chroot. If empty or omitted, no users will be allowed root` `access without a password (but if a user or a group they belong to is in` *users*` or `*groups*`, respectively, they may gain access with a` `password). See the section “`*Security*`” below.` - ***root-groups=****group1,group2,...* `A comma-separated list of groups which are allowed `**password-less**` root` `access to the chroot. If empty or omitted, no users will be allowed root` `access without a password (but if a user or a group they belong to is in` *users*` or `*groups*`, respectively, they may gain access with a` `password). See the section “`*Security*`” below.` - ***aliases=****alias1,alias2,...* `A comma-separated list of aliases (alternate names) for this chroot. For` `example, a chroot named “sid” might have an ‘unstable’ alias` `for convenience. Aliases are subject to the same naming restrictions as the` `chroot name itself.` - ***profile=****directory* - ***script-config=****filename* `The behaviour of the chroot setup scripts may be customised on a per-chroot` `basis by setting a specific configuration profile. The directory is relative` `to `*/etc/schroot*`. The default is ‘default’. The files` `in this directory are sourced by the setup scripts, and so their behaviour may` `be customised by selecting the appropriate profile. Alternatives are` `‘minimal’ (minimal configuration), ‘desktop’ (for running` `desktop applications in the chroot, making more functionality from the host` `system available in the chroot) and ‘sbuild’ (for using the chroot for` `Debian package building). Other packages may provide additional profiles. The` `default values of the keys `*setup.config*`, `*setup.copyfiles*`,` *setup.fstab*` and `*setup.nssdatabases*` are set based upon the` *profile*` setting.` - `Note that the `*profile*` key replaces the older `*script-config* `key. The `*script-config*` key is exactly the same as `*profile*`,` `but has “`*/config*`” appended to it. The default filename is` `‘default/config’. Either of these keys may be used. If both are` `present, then `*script-config*` will take precedence (`*profile* `will be unset). `*script-config*` is deprecated and will be removed in a` `future release. Note that `*profile*` is equivalent to` *script-config*` if the file sourced by `*script-config*` only` `contains the standard variables provided by schroot; if any additional` `variables or shell script fragments have been added, please also set` *setup.config*`, which will continue to allow this file to be sourced.` `It is recommended to replace the use of the sourced file with additional keys` `in schroot.conf where possible, but it will continue to be possible to source` `an additional configuration file using `*setup.config*`.` - `Desktop users should note that the fstab file `*desktop/fstab*` will need` `editing if you use gdm3; please see the comments in this file for further` `instructions. The `*preserve-environment*` key should also be set to` `‘true’ so that the environment is preserved inside the chroot.` - `If none of the configuration profiles provided above meet your needs, then they` `may be edited to further customise them, and/or copied and used as a template` `for entirely new profiles.` - `Note that the different profiles have different security implications; see the` `section “`*Security*`” below for further details.` - ***setup.config=****filename* `This key specifies a file which the setup scripts will source when they are` `run. This defaults to the same value as set by `*script-config*`. The` `file is a Bourne shell script, and in consequence may contain any valid shell` `code, in addition to simple variable assignments. This will, for example,` `allow behaviour to be customised according to the specific chroot type or name.` `Note that the script will be sourced once for each and every script invocation,` `and must be idempotent.` - `All the default settings in this file are now settable using configuration keys` `in `*schroot.conf*`, as detailed below. Existing configurations should be` `modified to use these keys in place of this file. See` [**schroot-script-config**(5)](/schroot-script-config/5.md) `for further details. This type of setup script configuration file is no longer` `provided as part of the standard profiles, but will continue to be sourced if` `present and this key is set.` - ***setup.copyfiles=****filename* `A file containing a list of files to copy into the chroot (one file per line).` `The file will have the same absolute location inside the chroot.` - ***setup.fstab=****filename* `The filesystem table file to be used to mount filesystems within the chroot.` `The format of this file is the same as for `*/etc/fstab*`, documented in` [**fstab**(5)](/fstab/5.md). `The only difference is that the mountpoint path `*fs\_dir*` is relative to the` `chroot, rather than the root. Also note that mountpoints are canonicalised on` `the host, which will ensure that absolute symlinks point inside the chroot, but` `complex paths containing multiple symlinks may be resolved incorrectly; it is` `inadvisable to use nested symlinks as mountpoints.` - ***setup.nssdatabases=****filename* `A file listing the system databases to copy into the chroot. The default` `databases are ‘passwd’, ‘shadow’, ‘group’ and` `‘gshadow’. Other potential databases which could be added include` `‘services’, ‘protocols’, ‘networks’, and` `‘hosts’. The databases are copied using` [**getent**(1)](/getent/1.md) `so all database sources listed in `*/etc/nsswitch.conf*` will be used for` `each database.` - ***setup.services=****service1,service2,...* `A comma-separated list of services to run in the chroot. These will be started` `when the session is started, and stopped when the session is ended.` - ***command-prefix=****command,option1,option2,...* `A comma-separated list of a command and the options for the command. This` `command and its options will be prefixed to all commands run inside the chroot.` `This is useful for adding commands such as nice, ionice or eatmydata for all` `commands run inside the chroot. nice and ionice will affect CPU and I/O` `scheduling. eatmydata ignores filesystem fsync operations, and is useful for` `throwaway snapshot chroots where you don't care about dataloss, but do care` `about high speed.` - ***personality=****persona* `Set the personality (process execution domain) to use. This option is useful` `when using a 32-bit chroot on 64-bit system, for example. Valid options on` `Linux are ‘bsd’, ‘hpux’, ‘irix32’, ‘irix64’,` `‘irixn32’, ‘iscr4’, ‘linux’, ‘linux32’,` `‘linux_32bit’, ‘osf4’, ‘osr5’, ‘riscos’,` `‘scorvr3’, ‘solaris’, ‘sunos’, ‘svr4’,` `‘uw7’, ‘wysev386’, and ‘xenix’. The default value is` `‘linux’. There is also the special option ‘undefined’` `(personality not set). For a 32-bit chroot on a 64-bit system,` `‘linux32’ is the option required. The only valid option for non-Linux` `systems is ‘undefined’. The default value for non-Linux systems is` `‘undefined’.` - ***preserve-environment=****true*`|`*false* `By default, the environment will not be preserved inside the chroot, instead a` `minimal environment will be used. Set to `*true*` to always preserve the` `environment. This is useful for example when running X applications inside the` `chroot, which need the environment to function correctly. The environment may` `also be preserved using the `*--preserve-environment*` option.` - ***shell=****shell* `When running a login shell a number of potential shells will be considered, in` `this order: the command in the SHELL environment variable (if` *--preserve-environment*` is used, or `*preserve-environment*` is` `enabled), the user's shell in the ‘passwd’ database, `*/bin/bash* `and finally `*/bin/sh*`. This setting overrides this list, and will use the` `shell specified. It may be overridden using the `*--shell*` option.` - ***environment-filter=****regex* `The environment to be set in the chroot will be filtered in order to remove` `environment variables which may pose a security risk. Any environment variable` `matching the specified POSIX extended regular expression will be removed prior` `to executing any command in the chroot.` - `Potentially dangerous environment variables are removed for safety by default` `using the following regular expression:` `“^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$”.` ### Plain and directory chroots `Chroots of type ‘plain’ or ‘directory’ are directories` `accessible in the filesystem. The two types are equivalent except for the fact` `that directory chroots run setup scripts, whereas plain chroots do not. In` `consequence, filesystems such as `*/proc*` are not mounted in plain chroots;` `it is the responsibility of the system administrator to configure such chroots` `by hand, whereas directory chroots are automatically configured. Additionally,` `directory chroots implement the `**filesystem union chroot**` options (see` `“`*Filesystem Union chroot options*`”, below).` `These chroot types have an additional (mandatory) configuration option:` - ***directory=****directory* `The directory containing the chroot environment. This is where the root will` `be changed to when executing a login shell or a command. The directory must` `exist and have read and execute permissions to allow users access to it. Note` `that on Linux systems it will be bind-mounted elsewhere for use as a chroot;` `the directory for ‘plain’ chroots is mounted with the `*--rbind* `option to` [**mount**(8)](/mount/8.md), `while for ‘directory’ chroots `*--bind*` is used instead so that` `sub-mounts are not preserved (they should be set in the `*fstab*` file just` `like in `*/etc/fstab*` on the host).` ### File chroots `Chroots of type ‘file’ are files on the current filesystem containing` `an archive of the chroot files. They implement the `**source chroot**` options` `(see “`*Source chroot options*`”, below). Note that a corresponding` `source chroot (of type ‘file’) will be created for each chroot of this` `type; this is for convenient access to the source archive, e.g. for the purpose` `of updating. These additional options are also implemented:` - ***file=****filename* `The file containing the archived chroot environment (mandatory). This must be` `a tar (tape archive), optionally compressed with gzip, bzip2, xz, lzop or lz4.` `The file extensions used to determine the type are `*.tar*`,` *.tar.gz*`, `*.tar.bz2*`, `*.tar.xz*`, `*.tar.lzop*`, `*.tar.lz4*`,` *.tgz*`, `*.tbz*`, `*.txz*`, `*.tzo*` and `*.tlz4*`. This file must` `be owned by the root user, and not be writable by other. Note that zip` `archives are no longer supported; zip was not able to archive named pipes and` `device nodes, so was not suitable for archiving chroots.` - ***location=****path* `This is the path to the chroot `*inside*` the archive. For example, if the` `archive contains a chroot in `*/squeeze*`, you would specify` `“/squeeze” here. If the chroot is the only thing in the archive,` `i.e. `*/*` is the root filesystem for the chroot, this option should be left` `blank, or omitted entirely.` ### Loopback chroots `Chroots of type ‘loopback’ are a filesystem available as a file on` `disk, accessed via a loopback mount. The file will be loopback mounted and` `unmounted on demand. Loopback chroots implement the `**mountable chroot**` and` **filesystem union chroot**` options (see “`*Mountable chroot* *options*`” and “`*Filesystem Union chroot options*`”, below),` `plus an additional option:` - ***file=****filename* `This is the filename of the file containing the filesystem, including the` `absolute path. For example “/srv/chroot/sid”.` ### Block device chroots `Chroots of type ‘block-device’ are a filesystem available on an` `unmounted block device. The device will be mounted and unmounted on demand.` `Block device chroots implement the `**mountable chroot**` and `**filesystem** **union chroot**` options (see “`*Mountable chroot options*`” and` `“`*Filesystem Union chroot options*`”, below), plus an additional` `option:` - ***device=****device* `This is the device name of the block device, including the absolute path. For` `example, “/dev/sda5”.` ### Btrfs snapshot chroots `Chroots of type ‘btrfs-snapshot’ are a Btrfs snapshot created from an` `existing Btrfs subvolume on a mounted Btrfs filesystem. A snapshot will be` `created from this source subvolume on demand at the start of a session, and` `then the snapshot will be mounted. At the end of the session, the snapshot` `will be unmounted and deleted. This chroot type implements the `**source** **chroot**` options (see “`*Source chroot options*`”, below). Note` `that a corresponding source chroot (of type ‘directory’) will be` `created for each chroot of this type; this is for convenient access to the` `source volume. These additional options are also implemented:` - ***btrfs-source-subvolume=****directory* `The directory containing the source subvolume.` - ***btrfs-snapshot-directory=****directory* `The directory in which to store the snapshots of the above source subvolume.` ### ZFS snapshot chroots `Chroots of type ‘zfs-snapshot’ are a ZFS clone created from an` `existing ZFS dataset. A snapshot and clone will be created from this source` `subvolume on demand at the start of a session, and then the clone will be` `mounted. At the end of the session, the clone will be unmounted and the` `clone and snapshot will be deleted. This chroot type implements the` **source chroot**` options (see “`*Source chroot options*`”,` `below). Note that a corresponding source chroot (of type` `‘directory’) will be created for each chroot of this type; this is` `for convenient access to the source volume. These additional options are` `also implemented:` - ***zfs-dataset=****dataset\_name* `Name of the ZFS source dataset to use.` - ***zfs-snapshot-options=****snapshot\_options* `Snapshot options. These are additional options to pass to zfs snapshot.` ### LVM snapshot chroots `Chroots of type ‘lvm-snapshot’ are a filesystem available on an LVM` `logical volume (LV). A snapshot LV will be created from this LV on demand, and` `then the snapshot will be mounted. At the end of the session, the snapshot LV` `will be unmounted and removed.` `LVM snapshot chroots implement the `**source chroot**` options (see` `“`*Source chroot options*`”, below), and all the options for` `‘block-device’. Note that a corresponding source chroot (of type` `‘block-device’) will be created for each chroot of this type; this is` `for convenient access to the source device. This additional option is also` `implemented:` - ***lvm-snapshot-options=****snapshot\_options* `Snapshot options. These are additional options to pass to lvcreate(8). For` `example, “-L 2g” to create a snapshot 2 GiB in size.` **Note:** `the LV name (`*-n*`), the snapshot option (`*-s*`) and the original LV` `path may not be specified here; they are set automatically by schroot.` ### Custom chroots `Chroots of type ‘custom’ are a special type of chroot, used for` `implementing new types of chroot not supported by any of the above chroot` `types. This may be useful for implementing and testing a new chroot type` `without needing to write any C++ code. However, you will need to write your` `own setup script to do the setup work, since by itself this chroot type does` `very little. You will also need to add custom keys to your chroot definition` `for use in the setup script; unlike the configuration for the above chroot` `types, no validation of the options will take place unless you do it yourself` `in your custom setup script. These additional options are also implemented:` - ***custom-session-cloneable=****true*`|`*false* `Set whether or not sessions may be cloned using this chroot (enabled by` `default).` - ***custom-session-purgeable=****true*`|`*false* `Set whether or not sessions may be cloned using this chroot (disabled by` `default).` - ***custom-source-cloneable=****true*`|`*false* `Set whether or not source chroots may be cloned using this chroot (disabled by` `default).` ### Source chroot options `The ‘btrfs-snapshot’, ‘file’ and ‘lvm-snapshot’ chroot` `types implement source chroots. Additionally, chroot types with union support` `enabled implement source chroots (see “`*Filesystem Union chroot* *options*`”, below). These are chroots which automatically create a copy` `of themselves before use, and are usually session managed. These chroots` `additionally provide an extra chroot in the `*source:*` namespace, to allow` `convenient access to the original (non-snapshotted) data, and to aid in chroot` `maintenance. I.e. for a chroot named `*wheezy*` (`*chroot:wheezy*`), a` `corresponding `*source:wheezy*` chroot will be created. For compatibility` `with older versions of schroot which did not support namespaces, a chroot with` `a `*-source*` suffix appended to the chroot name will be created in addition` `(i.e. `*wheezy-source*` using the above example). Note that these` `compatibility names will be removed in schroot 1.5.0, so the use of the` *source:*` namespace is preferred over the use of the `*-source*` suffix` `form. See` [**schroot**(1)](/schroot/1.md) `for further details.` `These chroots provide the following additional options:` - ***source-clone=****true*`|`*false* `Set whether the source chroot should be automatically cloned (created) for this` `chroot. The default is `*true*` to automatically clone, but if desired` `may be disabled by setting to `*false*`. If disabled, the source chroot` `will be inaccessible.` - ***source-users=****user1,user2,...* `A comma-separated list of users which are allowed access to the source chroot.` `If empty or omitted, no users will be allowed access. This will become the` *users*` option in the source chroot.` - ***source-groups=****group1,group2,...* `A comma-separated list of groups which are allowed access to the source chroot.` `If empty or omitted, no users will be allowed access. This will become the` *groups*` option in the source chroot.` - ***source-root-users=****user1,user2,...* `A comma-separated list of users which are allowed `**password-less**` root` `access to the source chroot. If empty or omitted, no users will be allowed` `root access without a password (but if a user is in `*users*`, they may` `gain access with a password). This will become the `*root-users*` option` `in the source chroot. See the section “`*Security*`” below.` - ***source-root-groups=****group1,group2,...* `A comma-separated list of groups which are allowed `**password-less**` root` `access to the source chroot. If empty or omitted, no users will be allowed` `root access without a password (but if a user's group is in `*groups*`,` `they may gain access with a password). This will become the` *root-groups*` option in the source chroot. See the section` `“`*Security*`” below.` ### Mountable chroot options `The ‘block-device’, ‘loopback’ and ‘lvm-snapshot’` `chroot types implement device mounting. These are chroots which require the` `mounting of a device in order to access the chroot. These chroots provide the` `following additional options:` - ***mount-options=****options* `Mount options for the block device. These are additional options to pass to` [**mount**(8)](/mount/8.md). `For example, “-o atime,sync,user_xattr”.` - ***location=****path* `This is the path to the chroot `*inside*` the filesystem on the device. For` `example, if the filesystem contains a chroot in `*/chroot/sid*`, you would` `specify “/chroot/sid” here. If the chroot is the only thing on the` `filesystem, i.e. `*/*` is the root filesystem for the chroot, this option` `should be left blank, or omitted entirely.` ### Filesystem Union chroot options `The ‘block-device’, ‘directory’ and ‘loopback’ chroot` `types allow for the creation of a session using filesystem unions to overlay` `the original filesystem with a separate writable directory. The original` `filesystem is read-only, with any modifications made to the filesystem made in` `the overlying writable directory, leaving the original filesystem unchanged. A` `union permits multiple sessions to access and make changes to a single chroot` `simultaneously, while keeping the changes private to each session. To enable` `this feature, set `*union-type*` to any supported value. If enabled, the` `chroot will also be a `**source chroot**`, which will provide additional` `options (see “`*Source chroot options*`”, above). All entries are` `optional.` - ***union-type=****type* `Set the union filesystem type. Currently supported filesystems are` `‘aufs’, ‘overlayfs’, ‘overlay’ (as of Linux 4.0+) and` `‘unionfs’. The default is ‘none’, which disables this feature.` - ***union-mount-options=****options* `Union filesystem mount options (branch configuration), used for mounting the` `union filesystem specified with `*union-type*`. This replaces the complete` `“-o” string for mount and allows for the creation of complex` `filesystem unions. Note that ‘aufs’, ‘overlayfs’ and` `‘unionfs’ each have different supported mount options.` **Note:** `One can use the variables “${CHROOT_UNION_OVERLAY_DIRECTORY}” and` `“${CHROOT_UNION_UNDERLAY_DIRECTORY}” to refer to the writable overlay` `session directory and read-only underlying directory which are to form the` `union. See` [**schroot-setup**(5)](/schroot-setup/5.md) `for a complete variable list.` - ***union-overlay-directory****=directory* `Specify the directory where the writeable overlay session directories will be` `created. The default is ‘/var/lib/schroot/union/overlay’.` - ***union-underlay-directory****=directory* `Specify the directory where the read-only underlying directories will be` `created. The default is ‘/var/lib/schroot/union/underlay’.` ### Customisation `In addition to the configuration keys listed above, it is possible to add` `custom keys. These keys will be used to add additional environment` `variables to the setup script environment when setup scripts are run. The only` `restriction is that the key name consists only of alphanumeric characters and` `hyphens, begins with an alphabet character and contains at least one period.` `That is to say, that it matches the extended regular expression` `“^([a-z][a-z0-9]*\.)+[a-z][a-z0-9-]*$”.` `For example:` ``` debian.apt-update=true debian.distribution=unstable ``` `would set the following environment:` ``` DEBIAN_APT_UPDATE=true DEBIAN_DISTRIBUTION=unstable ``` `Note that it is an error to use different key names which would set the same` `environment variable by mixing periods and hyphens.` `Custom configuration keys may also be modified at runtime using the` *--option*` option. However, for security, only selected keys may be` `modified. These keys are specified using the following options:` - ***user-modifiable-keys=****key1,key2,..* `Set the keys which users may modify using `*--option*`.` - ***root-modifiable-keys=****key1,key2,..*` Set the keys which the` `root user may modify using `*--option*`. Note that the root user may use` `the keys specified in `*user-modifiable-keys*` in addition to those` `specified here.` ### Localisation `Some keys may be localised in multiple languages. This is achieved by adding` `the locale name in square brackets after the key name. For example:` ``` description[en_GB]=British English translation ``` `This will localise the `*description*` key for the en_GB locale.` ``` description[fr]=French translation ``` `This will localise the `*description*` key for all French locales.` ## CHROOT NAMES `A number of characters or words are not permitted in a chroot name,` `session name or configuration filename. The name must begin with a` `lowercase or an uppercase letter, or a digit. The remaining characters` `may additionally be dash (‘-’), period (‘.’), or` `underscore (‘_’).` `The rationale for these restrictions is as follows:` - Generic `Unfortunately, not all the places that deal with chroot names can` `handle non-printable and other characters properly, and it's hard to` `update all of them. This is mostly about the various shell scripts` `where it's also unwise to assume authors always create safe code.` - ‘**dpkg-old**’ ‘**dpkg-dist**’ ‘**dpkg-new**’ ‘**dpkg-tmp**’ `These names may not appear at the end of a name. These are saved copies of` `conffiles used by the dpkg package manager, and will be ignored.` ## SECURITY ### Untrusted users `Note that giving untrusted users root access to chroots is a `**serious** **security risk**`! Although the untrusted user will only have root access to` `files inside the chroot, in practice there are many obvious ways of breaking` `out of the chroot and of disrupting services on the host system. As always,` `this boils down to `*trust*`.` **Do not give chroot root access to users you would not trust** **with root access to the host system.** ### Profiles `Depending upon which profile you have configured with the` *script-config*` option, different filesystems will be mounted inside` `the chroot, and different files will be copied into the chroot from the host.` `Some profiles will mount the host's `*/dev*`, while others will not. Some` `profiles also bind mount additional parts of the host filesystem in order to` `allow use of certain features, including user's home directories and specific` `parts of `*/var*`. Check the profile's `*fstab*` file to be certain of` `what will be mounted, and the other profile files to see which files and system` `databases will be copied into the chroot. Choose a different profile or edit` `the files to further restrict what is made available inside the chroot.` `There is a tradeoff between security (keeping the chroot as minimal as` `possible) and usability (which sometimes requires access to parts of the host` `filesystem). The different profiles make different tradeoffs, and it is` `important that you assess which meets the security/usability tradeoff you` `require.` ## EXAMPLE ``` # Sample configuration [sid] type=plain description=Debian unstable description[fr_FR]=Debian instable directory=/srv/chroot/sid priority=3 users=jim groups=sbuild root-users=rleigh aliases=unstable,default [etch] type=block-device description=Debian testing (32-bit) priority=2 groups=users #groups=sbuild-security aliases=testing device=/dev/hda_vg/etch_chroot mount-options=-o atime personality=linux32 [sid-file] type=file description=Debian sid file-based chroot priority=3 groups=sbuild file=/srv/chroots/sid.tar.gz [sid-snapshot] type=lvm-snapshot description=Debian unstable LVM snapshot priority=3 groups=sbuild users=rleigh source-root-users=rleigh source-root-groups=admin device=/dev/hda_vg/sid_chroot mount-options=-o atime,sync,user_xattr lvm-snapshot-options=--size 2G ``` ## FILES ### Chroot definitions - ***/etc/schroot/schroot.conf*** `The system-wide chroot definition file. This file must be owned by the root` `user, and not be writable by other.` - ***/etc/schroot/chroot.d*** `Additional chroot definitions may be placed in files under this directory.` `They are treated in exactly that same manner as `*/etc/schroot/schroot.conf*`. Each` `file may contain one or more chroot definitions.` ### Setup script configuration `The directory `***/etc/schroot/default***` contains the default` `settings used by setup scripts.` - ***config*** `Main configuration file read by setup scripts. The format of this file is` `described in` [**schroot-script-config**(5)](/schroot-script-config/5.md). `This is the default value for the `*script-config*` key. Note that this` `was formerly named `*/etc/schroot/script-defaults*`. The following` `files are referenced by default:` - ***copyfiles*** `A list of files to copy into the chroot from the host system. Note that this` `was formerly named `*/etc/schroot/copyfiles-defaults*`.` - ***fstab*** `A file in the format described in` [**fstab**(5)](/fstab/5.md), `used to mount filesystems inside the chroot. The mount location is relative to` `the root of the chroot. Note that this was formerly named` */etc/schroot/mount-defaults*`.` - ***nssdatabases*** `System databases (as described in `*/etc/nsswitch.conf*` on GNU/Linux` `systems) to copy into the chroot from the host. Note that this was formerly` `named `*/etc/schroot/nssdatabases-defaults*`.` ## AUTHORS `Roger Leigh.` ## COPYRIGHT `Copyright © 2005-2012 Roger Leigh ` **schroot**` is free software: you can redistribute it and/or` `modify it under the terms of the GNU General Public License as` `published by the Free Software Foundation, either version 3 of the` `License, or (at your option) any later version.` ## SEE ALSO [**sbuild**(1)](/sbuild/1.md), [**schroot**(1)](/schroot/1.md), [**schroot-script-config**(5)](/schroot-script-config/5.md), [**schroot-faq**(7)](/schroot-faq/7.md), [**mount**(8)](/mount/8.md).