| 2012-12-27 09:51:49 |
Stéphane Gourichon |
description |
------------------------------------------------------------------------
# Short report
* chroot does not modify target, schroot expected to do the same, or at least warn users in documentation
* expected behavior: do not overwrite important config files (like /etc/passwd)
* observed behavior: overwrite important config files (like /etc/passwd) without any backup (9 files overwritten in recommended setup, several), run-time warning or documentation
* older releases of schroot (that did not include destructive setup scripts) did not have this behavior
------------------------------------------------------------------------
Long report below, with suggestions for fixes.
# Introduction, or where expectations come from
schroot fills some gaps left by plain chroot and that makes it a valuable tool. schroot makes two things easier:
* easily provide environment that plain chroot command does not provide (mainly mount points, network config, but also kernel personalities)
* allow regular users to use the chrooted environment
Example uses of chroot:
* building another system that will live on its own later on (you need /proc /sys etc but don't want to replicate host configuration). Guest system may be different distribution, newer version of current distribution, will have different services, sets of users, etc.
* rescuing another, independent, system (you need /proc /sys etc but don't want to replicate host configuration).
* slave subsystems (compatible kernel, different libraries) as extension of the host system (with same set of users etc).
chroot is not limited to the third case, but scripts in current schroot seem to narrow schroot, which would otherwise be highly useful for all cases above.
In any case, no one likes a tool overwriting important system configuration without even a word of warning in the documentation.
# Steps to reproduce
* read man schroot and man schroot.conf
* observe that man schroot.conf recommends "type=directory", mentions setup scripts without warning that these scripts overwrite without backup. As a consequence, expect "setup script" to mean e.g. a script running mount but not changing any file inside chroot.
* observe that man schroot.conf explains "script-config=" as per-chroot customization without ever mentioning that they actually overwrite guest system configuration with copy from host, which may not always be what the user wants.
* create a simple config for a guest system (e.g. for rescue) with default, since it's recommended
* expect it to mount your environment plus /proc /sys but not destroy data.
* run
# Observed behavior
In guest's etc, files resolv.conf, gshadow, passwd, shadow, group,
services, protocols, networks and hosts have been irreversibly
overwritten with irrelevant copies from host. (Such behavior is
relevant in some use case of chroots, but not all.)
# Expected behavior
Do not delete user data unless the user clearly wants that.
Any behavior that risks loss of data:
* either does not happen in default behavior or recommended setup
* or causes a warning and pause in program run (with option to avoid)
* or at least is clearly documented as such so that a user configuring the program will see the warning in associated documentation
# Suggested fixes
## Change the man page so that danger is documented
Following sections seem relevant in man schroot.conf.
### type=type
Suggested changes.
Before:
> Note that ‘plain’ chroots do not run setup scripts and mount filesystems; ‘directory’ is recommended for normal use (see “Plain and directory chroots”, below).
After:
> Note that ‘plain’ chroots do not run setup scripts and mount filesystems; ‘directory’ is recommended for normal use (see “Plain and directory chroots”, below) but you should be warned that default setup scripts overwrite files in chroot.
### script-config=filename
Suggested changes.
Before:
> 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.
After:
> 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. WARNING: Configuration here means overwriting important system files such as /etc/passwd (at least with default scripts, even in "minimal" setup). If this is not what you want, either only ever use "type=plain" (and lose mount functionality) or make your own setup that overwrites only some files (or even none at all).
## Provide a non-destructive config and advertise it
E.g. /etc/schroot/safe would contain a copy of default config but with everything in nssdatabases and copyfiles commented out. The user still benefits from automatic mounts.
In section "script-config=filename", alternatives :
> ‘safe/config’ that does not modify any file in the chroot environment
## Label all configs that assume a slave system as such
This way, it is clear what use cases consider the guest system to be a slave with replicated stuff (users, network).
slave-default/config
slave-minimal/config
slave-desktop/config
slave-sbuild/config
safe/config
## Make backups of overwritten files
Provide a safety net, with perhaps an option in config file like backup-overwritten-files that default to true.
In /etc/schroot/setup.d/20copyfiles
Before:
cp --preserve=all $CP_VERBOSE "$1" "$2"
After:
cp --backup --suffix=.schroot-backup --preserve=all $CP_VERBOSE "$1" "$2"
In /etc/schroot/setup.d/20nssdatabases
Before:
getent "$1" > "$2"
After:
getent "$1" > "$2".tmp
mv --backup --suffix=.schroot-backup "$2".tmp "$2"
## Consider "mounting filesystems" and "copying files" as decorrelated features.
While mounting /proc /sys /dev is needed in many uses of a chroot
environment, actually changing system files in guest environment is
useful only in some use cases (slave systems, not systems to rescue or
to be built to become independent later).
The current situation makes schroot less suitable when the guest system is not to be modified.
In practice, perhaps a flag in the chroot configuration like
"allow-modifying-target=" ?
## Group files to copy by feature
For example, think about all user-related files (*passwd, *shadow, *group) and provide some way to enable them at once, like an option "replicate-users=true". Similarly, most other config files mentioned here are related to network configuration and might be treated as a whole ?
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: schroot 1.4.25-1
ProcVersionSignature: Ubuntu 3.2.0-35.55-generic 3.2.34
Uname: Linux 3.2.0-35-generic x86_64
ApportVersion: 2.0.1-0ubuntu17
Architecture: amd64
Date: Thu Dec 27 07:22:06 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120419)
MarkForUpload: True
SourcePackage: schroot
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.schroot.schroot.conf: [modified]
modified.conffile..etc.schroot.setup.d.00check: [modified]
mtime.conffile..etc.schroot.schroot.conf: 2012-12-27T06:58:13.926230
mtime.conffile..etc.schroot.setup.d.00check: 2012-12-27T06:58:26.082376 |
------------------------------------------------------------------------
# Short report
* chroot does not modify target, schroot expected to do the same, or at least warn users in documentation
* expected behavior: do not overwrite important config files (like /etc/passwd)
* observed behavior: overwrite important config files (9 files overwritten in recommended setup, including /etc/passwd, shadow, group) without any backup, run-time warning or documentation
* older releases of schroot (that did not include destructive setup scripts) did not have this behavior
------------------------------------------------------------------------
Long report below, with suggestions for fixes.
# Introduction, or where expectations come from
schroot fills some gaps left by plain chroot and that makes it a valuable tool. schroot makes two things easier:
* easily provide environment that plain chroot command does not provide (mainly mount points, network config, but also kernel personalities)
* allow regular users to use the chrooted environment
Example uses of chroot:
* building another system that will live on its own later on (you need /proc /sys etc but don't want to replicate host configuration). Guest system may be different distribution, newer version of current distribution, will have different services, sets of users, etc.
* rescuing another, independent, system (you need /proc /sys etc but don't want to replicate host configuration).
* slave subsystems (compatible kernel, different libraries) as extension of the host system (with same set of users etc).
chroot is not limited to the third case, but scripts in current schroot seem to narrow schroot, which would otherwise be highly useful for all cases above.
In any case, no one likes a tool overwriting important system configuration without even a word of warning in the documentation.
# Steps to reproduce
* read man schroot and man schroot.conf
* observe that man schroot.conf recommends "type=directory", mentions setup scripts without warning that these scripts overwrite without backup. As a consequence, expect "setup script" to mean e.g. a script running mount but not changing any file inside chroot.
* observe that man schroot.conf explains "script-config=" as per-chroot customization without ever mentioning that they actually overwrite guest system configuration with copy from host, which may not always be what the user wants.
* create a simple config for a guest system (e.g. for rescue) with default, since it's recommended
* expect it to mount your environment plus /proc /sys but not destroy data.
* run
# Observed behavior
In guest's etc, files resolv.conf, gshadow, passwd, shadow, group,
services, protocols, networks and hosts have been irreversibly
overwritten with irrelevant copies from host. (Such behavior is
relevant in some use case of chroots, but not all.)
# Expected behavior
Do not delete user data unless the user clearly wants that.
Any behavior that risks loss of data:
* either does not happen in default behavior or recommended setup
* or causes a warning and pause in program run (with option to avoid)
* or at least is clearly documented as such so that a user configuring the program will see the warning in associated documentation
# Suggested fixes
## Change the man page so that danger is documented
Following sections seem relevant in man schroot.conf.
### type=type
Suggested changes.
Before:
> Note that ‘plain’ chroots do not run setup scripts and mount filesystems; ‘directory’ is recommended for normal use (see “Plain and directory chroots”, below).
After:
> Note that ‘plain’ chroots do not run setup scripts and mount filesystems; ‘directory’ is recommended for normal use (see “Plain and directory chroots”, below) but you should be warned that default setup scripts overwrite files in chroot.
### script-config=filename
Suggested changes.
Before:
> 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.
After:
> 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. WARNING: Configuration here means overwriting important system files such as /etc/passwd (at least with default scripts, even in "minimal" setup). If this is not what you want, either only ever use "type=plain" (and lose mount functionality) or make your own setup that overwrites only some files (or even none at all).
## Provide a non-destructive config and advertise it
E.g. /etc/schroot/safe would contain a copy of default config but with everything in nssdatabases and copyfiles commented out. The user still benefits from automatic mounts.
In section "script-config=filename", alternatives :
> ‘safe/config’ that does not modify any file in the chroot environment
## Label all configs that assume a slave system as such
This way, it is clear what use cases consider the guest system to be a slave with replicated stuff (users, network).
slave-default/config
slave-minimal/config
slave-desktop/config
slave-sbuild/config
safe/config
## Make backups of overwritten files
Provide a safety net, with perhaps an option in config file like backup-overwritten-files that default to true.
In /etc/schroot/setup.d/20copyfiles
Before:
cp --preserve=all $CP_VERBOSE "$1" "$2"
After:
cp --backup --suffix=.schroot-backup --preserve=all $CP_VERBOSE "$1" "$2"
In /etc/schroot/setup.d/20nssdatabases
Before:
getent "$1" > "$2"
After:
getent "$1" > "$2".tmp
mv --backup --suffix=.schroot-backup "$2".tmp "$2"
## Consider "mounting filesystems" and "copying files" as decorrelated features.
While mounting /proc /sys /dev is needed in many uses of a chroot
environment, actually changing system files in guest environment is
useful only in some use cases (slave systems, not systems to rescue or
to be built to become independent later).
The current situation makes schroot less suitable when the guest system is not to be modified.
In practice, perhaps a flag in the chroot configuration like
"allow-modifying-target=" ?
## Group files to copy by feature
For example, think about all user-related files (*passwd, *shadow, *group) and provide some way to enable them at once, like an option "replicate-users=true". Similarly, most other config files mentioned here are related to network configuration and might be treated as a whole ?
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: schroot 1.4.25-1
ProcVersionSignature: Ubuntu 3.2.0-35.55-generic 3.2.34
Uname: Linux 3.2.0-35-generic x86_64
ApportVersion: 2.0.1-0ubuntu17
Architecture: amd64
Date: Thu Dec 27 07:22:06 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120419)
MarkForUpload: True
SourcePackage: schroot
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.schroot.schroot.conf: [modified]
modified.conffile..etc.schroot.setup.d.00check: [modified]
mtime.conffile..etc.schroot.schroot.conf: 2012-12-27T06:58:13.926230
mtime.conffile..etc.schroot.setup.d.00check: 2012-12-27T06:58:26.082376 |
|
