1SCHROOT.CONF(5) Debian sbuild SCHROOT.CONF(5)
2
6 schroot.conf - chroot definition file for schroot
7
9 schroot.conf is a plain UTF-8 text file, describing the chroots avail‐
10 able for use with schroot.
11 Comments are introduced following a ‘#’ (“hash”) character at the
13 beginning of a line, or following any other text. All text right of
14 the ‘#’ is treated as a comment.
15 The configuration format is an INI-style format, split into groups of
17 key-value pairs separated by section names in square brackets.
18 General options
20 A chroot is defined as a group of key-value pairs, which is started by
21 a name in square brackets on a line by itself. The file may contain
22 multiple groups which therefore define multiple chroots.
23 A chroot definition is started by the name of the chroot in square
25 brackets. For example,
26 [sid]
28 The name is subject to certain naming restrictions. For further
30 details, see the section “Chroot Names” below.
31 This is then followed by several key-value pairs, one per line:
33 type=type
35 The type of the chroot. Valid types are ‘plain’, ‘directory’,
36 ‘file’, ‘loopback’, ‘block-device’, ‘btrfs-snapshot’, ‘zfs-snap‐
37 shot’ and ‘lvm-snapshot’. If empty or omitted, the default type
38 is ‘plain’. Note that ‘plain’ chroots do not run setup scripts
39 and mount filesystems; ‘directory’ is recommended for normal use
40 (see “Plain and directory chroots”, below).
41 description=description
43 A short description of the chroot. This may be localised for
44 different languages; see the section “Localisation” below.
45 priority=number
47 Set the priority of a chroot. number is a positive integer
48 indicating whether a distribution is older than another. For
49 example, “oldstable” and “oldstable-security” might be ‘0’,
50 while “stable” and “stable-security” are ‘1’, “testing” is ‘2’
51 and “unstable” is ‘3’. The values are not important, but the
52 difference between them is. This option is deprecated and no
53 longer used by schroot, but is still permitted to be used; it
54 will be obsoleted and removed in a future release.
55 message-verbosity=verbosity
57 Set the verbosity of messages printed by schroot when setting
58 up, running commands and cleaning up the chroot. Valid settings
59 are ‘quiet’ (suppress most messages), ‘normal’ (the default) and
60 ‘verbose’ (show all messages). This setting is overridden by
61 the options --quiet and --verbose.
62 users=user1,user2,...
64 A comma-separated list of users which are allowed access to the
65 chroot. If empty or omitted, no users will be allowed access
66 (unless a group they belong to is also specified in groups).
67 groups=group1,group2,...
69 A comma-separated list of groups which are allowed access to the
70 chroot. If empty or omitted, no groups of users will be allowed
71 access.
72 root-users=user1,user2,...
74 A comma-separated list of users which are allowed password-less
75 root access to the chroot. If empty or omitted, no users will
76 be allowed root access without a password (but if a user or a
77 group they belong to is in users or groups, respectively, they
78 may gain access with a password). See the section “Security”
79 below.
80 root-groups=group1,group2,...
82 A comma-separated list of groups which are allowed password-less
83 root access to the chroot. If empty or omitted, no users will
84 be allowed root access without a password (but if a user or a
85 group they belong to is in users or groups, respectively, they
86 may gain access with a password). See the section “Security”
87 below.
88 aliases=alias1,alias2,...
90 A comma-separated list of aliases (alternate names) for this
91 chroot. For example, a chroot named “sid” might have an ‘unsta‐
92 ble’ alias for convenience. Aliases are subject to the same
93 naming restrictions as the chroot name itself.
94 profile=directory
96 script-config=filename
98 The behaviour of the chroot setup scripts may be customised on a
99 per-chroot basis by setting a specific configuration profile.
100 The directory is relative to /etc/schroot. The default is
101 ‘default’. The files in this directory are sourced by the setup
102 scripts, and so their behaviour may be customised by selecting
103 the appropriate profile. Alternatives are ‘minimal’ (minimal
104 configuration), ‘desktop’ (for running desktop applications in
105 the chroot, making more functionality from the host system
106 available in the chroot) and ‘sbuild’ (for using the chroot for
107 Debian package building). Other packages may provide additional
108 profiles. The default values of the keys setup.config, set‐
109 up.copyfiles, setup.fstab and setup.nssdatabases are set based
110 upon the profile setting.
111 Note that the profile key replaces the older script-config key.
113 The script-config key is exactly the same as profile, but has
114 “/config” appended to it. The default filename is ‘default/con‐
115 fig’. Either of these keys may be used. If both are present,
116 then script-config will take precedence (profile will be unset).
117 script-config is deprecated and will be removed in a future
118 release. Note that profile is equivalent to script-config if
119 the file sourced by script-config only contains the standard
120 variables provided by schroot; if any additional variables or
121 shell script fragments have been added, please also set set‐
122 up.config, which will continue to allow this file to be sourced.
123 It is recommended to replace the use of the sourced file with
124 additional keys in schroot.conf where possible, but it will con‐
125 tinue to be possible to source an additional configuration file
126 using setup.config.
127 Desktop users should note that the fstab file desktop/fstab will
129 need editing if you use gdm3; please see the comments in this
130 file for further instructions. The preserve-environment key
131 should also be set to ‘true’ so that the environment is pre‐
132 served inside the chroot.
133 If none of the configuration profiles provided above meet your
135 needs, then they may be edited to further customise them, and/or
136 copied and used as a template for entirely new profiles.
137 Note that the different profiles have different security impli‐
139 cations; see the section “Security” below for further details.
140 setup.config=filename
142 This key specifies a file which the setup scripts will source
143 when they are run. This defaults to the same value as set by
144 script-config. The file is a Bourne shell script, and in conse‐
145 quence may contain any valid shell code, in addition to simple
146 variable assignments. This will, for example, allow behaviour
147 to be customised according to the specific chroot type or name.
148 Note that the script will be sourced once for each and every
149 script invocation, and must be idempotent.
150 All the default settings in this file are now settable using
152 configuration keys in schroot.conf, as detailed below. Existing
153 configurations should be modified to use these keys in place of
154 this file. See schroot-script-config(5) for further details.
155 This type of setup script configuration file is no longer pro‐
156 vided as part of the standard profiles, but will continue to be
157 sourced if present and this key is set.
158 setup.copyfiles=filename
160 A file containing a list of files to copy into the chroot (one
161 file per line). The file will have the same absolute location
162 inside the chroot.
163 setup.fstab=filename
165 The filesystem table file to be used to mount filesystems within
166 the chroot. The format of this file is the same as for
167 /etc/fstab, documented in fstab(5). The only difference is that
168 the mountpoint path fs_dir is relative to the chroot, rather
169 than the root. Also note that mountpoints are canonicalised on
170 the host, which will ensure that absolute symlinks point inside
171 the chroot, but complex paths containing multiple symlinks may
172 be resolved incorrectly; it is inadvisable to use nested sym‐
173 links as mountpoints.
174 setup.nssdatabases=filename
176 A file listing the system databases to copy into the chroot.
177 The default databases are ‘passwd’, ‘shadow’, ‘group’ and
178 ‘gshadow’. Other potential databases which could be added
179 include ‘services’, ‘protocols’, ‘networks’, and ‘hosts’. The
180 databases are copied using getent(1) so all database sources
181 listed in /etc/nsswitch.conf will be used for each database.
182 setup.services=service1,service2,...
184 A comma-separated list of services to run in the chroot. These
185 will be started when the session is started, and stopped when
186 the session is ended.
187 command-prefix=command,option1,option2,...
189 A comma-separated list of a command and the options for the com‐
190 mand. This command and its options will be prefixed to all com‐
191 mands run inside the chroot. This is useful for adding commands
192 such as nice, ionice or eatmydata for all commands run inside
193 the chroot. nice and ionice will affect CPU and I/O scheduling.
194 eatmydata ingores filesystem fsync operations, and is useful for
195 throwaway snapshot chroots where you don't care about dataloss,
196 but do care about high speed.
197 personality=persona
199 Set the personality (process execution domain) to use. This
200 option is useful when using a 32-bit chroot on 64-bit system,
201 for example. Valid options on Linux are ‘bsd’, ‘hpux’,
202 ‘irix32’, ‘irix64’, ‘irixn32’, ‘iscr4’, ‘linux’, ‘linux32’,
203 ‘linux_32bit’, ‘osf4’, ‘osr5’, ‘riscos’, ‘scorvr3’, ‘solaris’,
204 ‘sunos’, ‘svr4’, ‘uw7’, ‘wysev386’, and ‘xenix’. The default
205 value is ‘linux’. There is also the special option ‘undefined’
206 (personality not set). For a 32-bit chroot on a 64-bit system,
207 ‘linux32’ is the option required. The only valid option for
208 non-Linux systems is ‘undefined’. The default value for non-
209 Linux systems is ‘undefined’.
210 preserve-environment=true|false
212 By default, the environment will not be preserved inside the
213 chroot, instead a minimal environment will be used. Set to true
214 to always preserve the environment. This is useful for example
215 when running X applications inside the chroot, which need the
216 environment to function correctly. The environment may also be
217 preserved using the --preserve-environment option.
218 shell=shell
220 When running a login shell a number of potential shells will be
221 considered, in this order: the command in the SHELL environment
222 variable (if --preserve-environment is used, or preserve-envi‐
223 ronment is enabled), the user's shell in the ‘passwd’ database,
224 /bin/bash and finally /bin/sh. This setting overrides this
225 list, and will use the shell specified. It may be overridden
226 using the --shell option.
227 environment-filter=regex
229 The environment to be set in the chroot will be filtered in
230 order to remove environment variables which may pose a security
231 risk. Any environment variable matching the specified POSIX
232 extended regular expression will be removed prior to executing
233 any command in the chroot.
234 Potentially dangerous environment variables are removed for
236 safety by default using the following regular expression:
237 “^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR
238 |KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE
239 |RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$”.
240 Plain and directory chroots
242 Chroots of type ‘plain’ or ‘directory’ are directories accessible in
243 the filesystem. The two types are equivalent except for the fact that
244 directory chroots run setup scripts, whereas plain chroots do not. In
245 consequence, filesystems such as /proc are not mounted in plain
246 chroots; it is the responsibility of the system administrator to con‐
247 figure such chroots by hand, whereas directory chroots are automati‐
248 cally configured. Additionally, directory chroots implement the
249 filesystem union chroot options (see “Filesystem Union chroot options”,
250 below).
251 These chroot types have an additional (mandatory) configuration option:
253 directory=directory
255 The directory containing the chroot environment. This is where
256 the root will be changed to when executing a login shell or a
257 command. The directory must exist and have read and execute
258 permissions to allow users access to it. Note that on Linux
259 systems it will be bind-mounted elsewhere for use as a chroot;
260 the directory for ‘plain’ chroots is mounted with the --rbind
261 option to mount(8), while for ‘directory’ chroots --bind is used
262 instead so that sub-mounts are not preserved (they should be set
263 in the fstab file just like in /etc/fstab on the host).
264 File chroots
266 Chroots of type ‘file’ are files on the current filesystem containing
267 an archive of the chroot files. They implement the source chroot
268 options (see “Source chroot options”, below). Note that a correspond‐
269 ing source chroot (of type ‘file’) will be created for each chroot of
270 this type; this is for convenient access to the source archive, e.g.
271 for the purpose of updating. These additional options are also imple‐
272 mented:
273 file=filename
275 The file containing the archived chroot environment (mandatory).
276 This must be a tar (tape archive), optionally compressed with
277 gzip, bzip2, xz, lzop or lz4. The file extensions used to
278 determine the type are .tar, .tar.gz, .tar.bz2, .tar.xz,
279 .tar.lzop, .tar.lz4, .tgz, .tbz, .txz, .tzo and .tlz4. This
280 file must be owned by the root user, and not be writable by
281 other. Note that zip archives are no longer supported; zip was
282 not able to archive named pipes and device nodes, so was not
283 suitable for archiving chroots.
284 location=path
286 This is the path to the chroot inside the archive. For example,
287 if the archive contains a chroot in /squeeze, you would specify
288 “/squeeze” here. If the chroot is the only thing in the ar‐
289 chive, i.e. / is the root filesystem for the chroot, this option
290 should be left blank, or omitted entirely.
291 Loopback chroots
293 Chroots of type ‘loopback’ are a filesystem available as a file on
294 disk, accessed via a loopback mount. The file will be loopback mounted
295 and unmounted on demand. Loopback chroots implement the mountable
296 chroot and filesystem union chroot options (see “Mountable chroot
297 options” and “Filesystem Union chroot options”, below), plus an addi‐
298 tional option:
299 file=filename
301 This is the filename of the file containing the filesystem,
302 including the absolute path. For example “/srv/chroot/sid”.
303 Block device chroots
305 Chroots of type ‘block-device’ are a filesystem available on an
306 unmounted block device. The device will be mounted and unmounted on
307 demand. Block device chroots implement the mountable chroot and
308 filesystem union chroot options (see “Mountable chroot options” and
309 “Filesystem Union chroot options”, below), plus an additional option:
310 device=device
312 This is the device name of the block device, including the abso‐
313 lute path. For example, “/dev/sda5”.
314 Btrfs snapshot chroots
316 Chroots of type ‘btrfs-snapshot’ are a Btrfs snapshot created from an
317 existing Btrfs subvolume on a mounted Btrfs filesystem. A snapshot
318 will be created from this source subvolume on demand at the start of a
319 session, and then the snapshot will be mounted. At the end of the ses‐
320 sion, the snapshot will be unmounted and deleted. This chroot type
321 implements the source chroot options (see “Source chroot options”,
322 below). Note that a corresponding source chroot (of type ‘directory’)
323 will be created for each chroot of this type; this is for convenient
324 access to the source volume. These additional options are also imple‐
325 mented:
326 btrfs-source-subvolume=directory
328 The directory containing the source subvolume.
329 btrfs-snapshot-directory=directory
331 The directory in which to store the snapshots of the above
332 source subvolume.
333 ZFS snapshot chroots
335 Chroots of type ‘zfs-snapshot’ are a ZFS clone created from an existing
336 ZFS dataset. A snapshot and clone will be created from this source
337 subvolume on demand at the start of a session, and then the clone will
338 be mounted. At the end of the session, the clone will be unmounted and
339 the clone and snapshot will be deleted. This chroot type implements
340 the source chroot options (see “Source chroot options”, below). Note
341 that a corresponding source chroot (of type ‘directory’) will be cre‐
342 ated for each chroot of this type; this is for convenient access to the
343 source volume. These additional options are also implemented:
344 zfs-dataset=dataset_name
346 Name of the ZFS source dataset to use.
347 zfs-snapshot-options=snapshot_options
349 Snapshot options. These are additional options to pass to zfs
350 snapshot.
351 LVM snapshot chroots
353 Chroots of type ‘lvm-snapshot’ are a filesystem available on an LVM
354 logical volume (LV). A snapshot LV will be created from this LV on
355 demand, and then the snapshot will be mounted. At the end of the ses‐
356 sion, the snapshot LV will be unmounted and removed.
357 LVM snapshot chroots implement the source chroot options (see “Source
359 chroot options”, below), and all the options for ‘block-device’. Note
360 that a corresponding source chroot (of type ‘block-device’) will be
361 created for each chroot of this type; this is for convenient access to
362 the source device. This additional option is also implemented:
363 lvm-snapshot-options=snapshot_options
365 Snapshot options. These are additional options to pass to
366 lvcreate(8). For example, “-L 2g” to create a snapshot 2 GiB in
367 size. Note: the LV name (-n), the snapshot option (-s) and the
368 original LV path may not be specfied here; they are set automat‐
369 ically by schroot.
370 Custom chroots
372 Chroots of type ‘custom’ are a special type of chroot, used for imple‐
373 menting new types of chroot not supported by any of the above chroot
374 types. This may be useful for implementing and testing a new chroot
375 type without needing to write any C++ code. However, you will need to
376 write your own setup script to do the setup work, since by itself this
377 chroot type does very little. You will also need to add custom keys to
378 your chroot definition for use in the setup script; unlike the configu‐
379 ration for the above chroot types, no validation of the options will
380 take place unless you do it yourself in your custom setup script.
381 These additional options are also implemented:
382 custom-session-cloneable=true|false
384 Set whether or not sessions may be cloned using this chroot
385 (enabled by default).
386 custom-session-purgeable=true|false
388 Set whether or not sessions may be cloned using this chroot
389 (disabled by default).
390 custom-source-cloneable=true|false
392 Set whether or not source chroots may be cloned using this
393 chroot (disabled by default).
394 Source chroot options
396 The ‘btrfs-snapshot’, ‘file’ and ‘lvm-snapshot’ chroot types implement
397 source chroots. Additionally, chroot types with union support enabled
398 implement source chroots (see “Filesystem Union chroot options”,
399 below). These are chroots which automatically create a copy of them‐
400 selves before use, and are usually session managed. These chroots
401 additionally provide an extra chroot in the source: namespace, to allow
402 convenient access to the original (non-snapshotted) data, and to aid in
403 chroot maintenance. I.e. for a chroot named wheezy (chroot:wheezy), a
404 corresponding source:wheezy chroot will be created. For compatibility
405 with older versions of schroot which did not support namespaces, a
406 chroot with a -source suffix appended to the chroot name will be cre‐
407 ated in addition (i.e. wheezy-source using the above example). Note
408 that these compatibility names will be removed in schroot 1.5.0, so the
409 use of the source: namespace is preferred over the use of the -source
410 suffix form. See schroot(1) for further details.
411 These chroots provide the following additional options:
413 source-clone=true|false
415 Set whether the source chroot should be automatically cloned
416 (created) for this chroot. The default is true to automatically
417 clone, but if desired may be disabled by setting to false. If
418 disabled, the source chroot will be inaccessible.
419 source-users=user1,user2,...
421 A comma-separated list of users which are allowed access to the
422 source chroot. If empty or omitted, no users will be allowed
423 access. This will become the users option in the source chroot.
424 source-groups=group1,group2,...
426 A comma-separated list of groups which are allowed access to the
427 source chroot. If empty or omitted, no users will be allowed
428 access. This will become the groups option in the source
429 chroot.
430 source-root-users=user1,user2,...
432 A comma-separated list of users which are allowed password-less
433 root access to the source chroot. If empty or omitted, no users
434 will be allowed root access without a password (but if a user is
435 in users, they may gain access with a password). This will
436 become the root-users option in the source chroot. See the sec‐
437 tion “Security” below.
438 source-root-groups=group1,group2,...
440 A comma-separated list of groups which are allowed password-less
441 root access to the source chroot. If empty or omitted, no users
442 will be allowed root access without a password (but if a user's
443 group is in groups, they may gain access with a password). This
444 will become the root-groups option in the source chroot. See
445 the section “Security” below.
446 Mountable chroot options
448 The ‘block-device’, ‘loopback’ and ‘lvm-snapshot’ chroot types imple‐
449 ment device mounting. These are chroots which require the mounting of
450 a device in order to access the chroot. These chroots provide the fol‐
451 lowing additional options:
452 mount-options=options
454 Mount options for the block device. These are additional
455 options to pass to mount(8). For example, “-o
456 atime,sync,user_xattr”.
457 location=path
459 This is the path to the chroot inside the filesystem on the
460 device. For example, if the filesystem contains a chroot in
461 /chroot/sid, you would specify “/chroot/sid” here. If the
462 chroot is the only thing on the filesystem, i.e. / is the root
463 filesystem for the chroot, this option should be left blank, or
464 omitted entirely.
465 Filesystem Union chroot options
467 The ‘block-device’, ‘directory’ and ‘loopback’ chroot types allow for
468 the creation of a session using filesystem unions to overlay the origi‐
469 nal filesystem with a separate writable directory. The original
470 filesystem is read-only, with any modifications made to the filesystem
471 made in the overlying writable directory, leaving the original filesys‐
472 tem unchanged. A union permits multiple sessions to access and make
473 changes to a single chroot simultaneously, while keeping the changes
474 private to each session. To enable this feature, set union-type to any
475 supported value. If enabled, the chroot will also be a source chroot,
476 which will provide additional options (see “Source chroot options”,
477 above). All entries are optional.
478 union-type=type
480 Set the union filesystem type. Currently supported filesystems
481 are ‘aufs’, ‘overlayfs’, ‘overlay’ (as of Linux 4.0+) and
482 ‘unionfs’. The default is ‘none’, which disables this feature.
483 union-mount-options=options
485 Union filesystem mount options (branch configuration), used for
486 mounting the union filesystem specified with union-type. This
487 replaces the complete “-o” string for mount and allows for the
488 creation of complex filesystem unions. Note that ‘aufs’, ‘over‐
489 layfs’ and ‘unionfs’ each have different supported mount
490 options. Note: One can use the variables “${CHROOT_UNION_OVER‐
491 LAY_DIRECTORY}” and “${CHROOT_UNION_UNDERLAY_DIRECTORY}” to
492 refer to the writable overlay session directory and read-only
493 underlying directory which are to form the union. See sch‐
494 root-setup(5) for a complete variable list.
495 union-overlay-directory=directory
497 Specify the directory where the writeable overlay session direc‐
498 tories will be created. The default is ‘/var/lib/sch‐
499 root/union/overlay’.
500 union-underlay-directory=directory
502 Specify the directory where the read-only underlying directories
503 will be created. The default is ‘/var/lib/schroot/union/under‐
504 lay’.
505 Customisation
507 In addition to the configuration keys listed above, it is possible to
508 add custom keys. These keys will be used to add additional environment
509 variables to the setup script environment when setup scripts are run.
510 The only restriction is that the key name consists only of alphanumeric
511 characters and hyphens, begins with an alphabet character and contains
512 at least one period. That is to say, that it matches the extended reg‐
513 ular expression “^([a-z][a-z0-9]*\.)+[a-z][a-z0-9-]*$”.
514 For example:
516 debian.apt-update=true
517 debian.distribution=unstable
518 would set the following environment:
520 DEBIAN_APT_UPDATE=true
521 DEBIAN_DISTRIBUTION=unstable
522 Note that it is an error to use different key names which would set the
524 same environment variable by mixing periods and hyphens.
525 Custom configuration keys may also be modified at runtime using the
527 --option option. However, for security, only selected keys may be mod‐
528 ified. These keys are specified using the following options:
529 user-modifiable-keys=key1,key2,..
531 Set the keys which users may modify using --option.
532 root-modifiable-keys=key1,key2,.. Set the keys which the
534 root user may modify using --option. Note that the root user
535 may use the keys specified in user-modifiable-keys in addition
536 to those specified here.
537 Localisation
539 Some keys may be localised in multiple languages. This is achieved by
540 adding the locale name in square brackets after the key name. For
541 example:
542 description[en_GB]=British English translation
543 This will localise the description key for the en_GB locale.
545 description[fr]=French translation
546 This will localise the description key for all French locales.
548
550 A number of characters or words are not permitted in a chroot name,
551 session name or configuration filename. The name may not contain a
552 leading period (‘.’). The characters ‘:’ (colon), ‘,’ (comma) and ‘/’
553 (forward slash) are not permitted anywhere in the name. The name may
554 also not contain a trailing tilde (‘~’). The rationale for these
555 restrictions is given below.
556 ‘.’ A leading period could be used to create a name with a relative
558 path in it, in combination with ‘/’, and this could allow over‐
559 writing of files on the host filesystem. Not allowing this
560 character also means hidden files cannot be created. It also
561 means some editor backups are automatically ignored. Periods
562 are allowed anywhere else in the name.
563 ‘:’ A colon is used as a namespace delimiter, and so is not permit‐
565 ted as part of a chroot or session name. LVM snapshot names may
566 also not contain this character due to a naming restriction by
567 lvcreate(8).
568 ‘/’ Names containing this character are not valid filenames. A for‐
570 ward slash would potentially allow creation of files in subdi‐
571 rectories.
572 ‘,’ Commas are used to separate items in lists. Aliases are sepa‐
574 rated by commas and hence can't contain commas in their name.
575 ‘~’ Filenames containing trailing tildes are used for editor backup
577 files, which are ignored. Tildes are allowed anywhere else in
578 the name.
579 ‘dpkg-old’
581 ‘dpkg-dist’
582 ‘dpkg-new’
583 ‘dpkg-tmp’
584 These names may not appear at the end of a name. These are
585 saved copies of conffiles used by the dpkg package manager, and
586 will be ignored.
587
589 Untrusted users
590 Note that giving untrusted users root access to chroots is a serious
591 security risk! Although the untrusted user will only have root access
592 to files inside the chroot, in practice there are many obvious ways of
593 breaking out of the chroot and of disrupting services on the host sys‐
594 tem. As always, this boils down to trust.
595 Do not give chroot root access to users you would not trust with root
597 access to the host system.
598 Profiles
600 Depending upon which profile you have configured with the script-config
601 option, different filesystems will be mounted inside the chroot, and
602 different files will be copied into the chroot from the host. Some
603 profiles will mount the host's /dev, while others will not. Some pro‐
604 files also bind mount additional parts of the host filesystem in order
605 to allow use of certain features, including user's home directories and
606 specific parts of /var. Check the profile's fstab file to be certain
607 of what will be mounted, and the other profile files to see which files
608 and system databases will be copied into the chroot. Choose a differ‐
609 ent profile or edit the files to further restrict what is made avail‐
610 able inside the chroot.
611 There is a tradeoff between security (keeping the chroot as minimal as
613 possible) and usability (which sometimes requires access to parts of
614 the host filesystem). The different profiles make different tradeoffs,
615 and it is important that you assess which meets the security/usability
616 tradeoff you require.
617
619 # Sample configuration
620 [sid]
622 type=plain
623 description=Debian unstable
624 description[fr_FR]=Debian instable
625 directory=/srv/chroot/sid
626 priority=3
627 users=jim
628 groups=sbuild
629 root-users=rleigh
630 aliases=unstable,default
631 [etch]
633 type=block-device
634 description=Debian testing (32-bit)
635 priority=2
636 groups=users
637 #groups=sbuild-security
638 aliases=testing
639 device=/dev/hda_vg/etch_chroot
640 mount-options=-o atime
641 personality=linux32
642 [sid-file]
644 type=file
645 description=Debian sid file-based chroot
646 priority=3
647 groups=sbuild
648 file=/srv/chroots/sid.tar.gz
649 [sid-snapshot]
651 type=lvm-snapshot
652 description=Debian unstable LVM snapshot
653 priority=3
654 groups=sbuild
655 users=rleigh
656 source-root-users=rleigh
657 source-root-groups=admin
658 device=/dev/hda_vg/sid_chroot
659 mount-options=-o atime,sync,user_xattr
660 lvm-snapshot-options=--size 2G
661
663 Chroot definitions
664 /etc/schroot/schroot.conf
665 The system-wide chroot definition file. This file must be owned
666 by the root user, and not be writable by other.
667 /etc/schroot/chroot.d
669 Additional chroot definitions may be placed in files under this
670 directory. They are treated in exactly that same manner as
671 /etc/schroot/schroot.conf. Each file may contain one or more
672 chroot definitions.
673 Setup script configuration
675 The directory /etc/schroot/default contains the default settings used
676 by setup scripts.
677 config Main configuration file read by setup scripts. The format of
679 this file is described in schroot-script-config(5). This is the
680 default value for the script-config key. Note that this was
681 formerly named /etc/schroot/script-defaults. The following
682 files are referenced by default:
683 copyfiles
685 A list of files to copy into the chroot from the host system.
686 Note that this was formerly named /etc/schroot/copy‐
687 files-defaults.
688 fstab A file in the format decribed in fstab(5), used to mount
690 filesystems inside the chroot. The mount location is relative
691 to the root of the chroot. Note that this was formerly named
692 /etc/schroot/mount-defaults.
693 nssdatabases
695 System databases (as described in /etc/nsswitch.conf on
696 GNU/Linux systems) to copy into the chroot from the host. Note
697 that this was formerly named /etc/schroot/nssdatabases-defaults.
698
700 Roger Leigh.
701
703 Copyright © 2005-2012 Roger Leigh <rleigh@debian.org>
704 schroot is free software: you can redistribute it and/or modify it
706 under the terms of the GNU General Public License as published by the
707 Free Software Foundation, either version 3 of the License, or (at your
708 option) any later version.
709
711 sbuild(1), schroot(1), schroot-script-config(5), schroot-faq(7),
712 mount(8).
713Version 1.6.10 05 May 2014 SCHROOT.CONF(5)