schroot overwrites files in guest system without announcement or backup

[Stéphane Gourichon]

------------------------------------------------------------------------
# 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

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Roger Leigh (rleigh)]

This issue is already being tracked in the following bug reports:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565613
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557730

Note that this has been the default behaviour since schroot was written. What has changed which might have affected you is that older versions had the option to disable the setup scripts for all chroot types; they are now always run for all types except "plain" (which is identical to "directory" except that no setup scripts are run). Note that this is only the /default/ behaviour--what's copied is entirely configurable if this does not meet your needs.

This is definitely a problem, but it's not entirely clear what the best solution (or set of solutions) we need. Most chroot environments need the NSS databases syncing from the host, or else the entries for the current user etc. won't be present. The purpose of schroot is to automate this, rather than requiring manual updates by the admin. This works fine until you want something different in the chroot, or you add things inside the chroot which are then subsequently lost; however, synchronising this data one (or two) ways between the host and guest is decidedly non-trivial.

For the time being, it's simple enough to disable the behaviour: just edit /etc/schroot/$profile/nssdatabases (and/or copyfiles) and comment out the databases/files you don't want to be copied. Or you could create your own custom profile rather than modifiying one of the pre-canned profiles.

I'll look at making your suggested changes to the documentation.

If you could follow up to the original Debian reports rather than here, that would be appreciated. Thanks.

Regards,
Roger