Bug#401180: [Buildd-tools-devel] Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
On 12/12/06 at 21:28 +, Roger Leigh wrote: tags 401180 + patch thanks Lucas Nussbaum [EMAIL PROTECTED] writes: I am using file chroots. the chroot is usually untared under /var/lib/schroot, however, I wanted to change this to another location (my /var is quite small, and many apps don't like it being full). I couldn't find any way to specify another directory for this, so I just symlinked /var/lib/schroot to another place. However, this caused $LIBEXEC_DIR/schroot-listmounts to be unable to determine that /home, /tmp, etc were still bind-mounted. So do_umount_all in that file exits without error even if my filesystems are still bind-mounted, and my home directory and my /tmp got removed. I have attached a patch which I believe addresses this problem. Please could you build schroot with the patch applied and test under the same conditions (perhaps with a backup beforehand), to see if this fixes things. I have tested it myself, and I do think it works, but I would appreciate some confirmation before uploading a fixed version. Hi, I confirm that the patch seems to work: [EMAIL PROTECTED]:~$ /usr/lib/schroot/schroot-listmounts -m /var/lib/schroot/mount/tsid-b1b50cf3-c42b-405d-8ab8-0bae1a1c3637 /home/space/schroot/mount/tsid-b1b50cf3-c42b-405d-8ab8-0bae1a1c3637/tmp /home/space/schroot/mount/tsid-b1b50cf3-c42b-405d-8ab8-0bae1a1c3637/dev/shm /home/space/schroot/mount/tsid-b1b50cf3-c42b-405d-8ab8-0bae1a1c3637/dev/pts /home/space/schroot/mount/tsid-b1b50cf3-c42b-405d-8ab8-0bae1a1c3637/proc (I've disabled bind-mounting of /home in /etc/schroot/setup.d/10mount) After thinking about it for a while, I exited the chroot, and it didn't empty my /tmp. :-) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Bug#401180: [Buildd-tools-devel] Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
tags 401180 + pending thanks Lucas Nussbaum [EMAIL PROTECTED] writes: On 12/12/06 at 21:28 +, Roger Leigh wrote: I have attached a patch which I believe addresses this problem. Please could you build schroot with the patch applied and test under the same conditions (perhaps with a backup beforehand), to see if this fixes things. I have tested it myself, and I do think it works, but I would appreciate some confirmation before uploading a fixed version. I confirm that the patch seems to work: (I've disabled bind-mounting of /home in /etc/schroot/setup.d/10mount) A wise precaution! After thinking about it for a while, I exited the chroot, and it didn't empty my /tmp. :-) Thanks for your bravery in testing this one! I'll upload a fixed package this weekend. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpOMz7vPbFXQ.pgp Description: PGP signature
Bug#401180: [Buildd-tools-devel] Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
tags 401180 + patch thanks Lucas Nussbaum [EMAIL PROTECTED] writes: I am using file chroots. the chroot is usually untared under /var/lib/schroot, however, I wanted to change this to another location (my /var is quite small, and many apps don't like it being full). I couldn't find any way to specify another directory for this, so I just symlinked /var/lib/schroot to another place. However, this caused $LIBEXEC_DIR/schroot-listmounts to be unable to determine that /home, /tmp, etc were still bind-mounted. So do_umount_all in that file exits without error even if my filesystems are still bind-mounted, and my home directory and my /tmp got removed. I have attached a patch which I believe addresses this problem. Please could you build schroot with the patch applied and test under the same conditions (perhaps with a backup beforehand), to see if this fixes things. I have tested it myself, and I do think it works, but I would appreciate some confirmation before uploading a fixed version. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. Index: schroot/schroot-listmounts-main.cc === --- schroot/schroot-listmounts-main.cc (revision 1061) +++ schroot/schroot-listmounts-main.cc (working copy) @@ -22,6 +22,7 @@ #include schroot-listmounts-main.h #include cerrno +#include climits #include cstdio #include cstdlib #include ctime @@ -90,6 +91,12 @@ std::string to_find = sbuild::normalname(this-opts-mountpoint); + // NOTE: This is a non-standard GNU extension. + char *rpath = realpath(to_find.c_str(), NULL); + to_find = rpath; + free(rpath); + rpath = 0; + std::FILE *mntdb = std::fopen(mountfile.c_str(), r); if (mntdb == 0) throw error(mountfile, OPEN, strerror(errno)); pgpKJ6cE1oxPg.pgp Description: PGP signature
Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
On 01/12/06 at 16:47 -0800, Steve Langasek wrote:
severity 401180 important
thanks
On Fri, Dec 01, 2006 at 02:29:29PM +0100, Lucas Nussbaum wrote:
Package: schroot
Version: 1.0.3-1
Severity: critical
Justification: causes removal of /home
I am using file chroots. the chroot is usually untared under
/var/lib/schroot, however, I wanted to change this to another location
(my /var is quite small, and many apps don't like it being full).
I couldn't find any way to specify another directory for this, so I just
symlinked /var/lib/schroot to another place. However, this caused
$LIBEXEC_DIR/schroot-listmounts to be unable to determine that /home,
/tmp, etc were still bind-mounted. So do_umount_all in that file exits
without error even if my filesystems are still bind-mounted, and my home
directory and my /tmp got removed.
Symlinking system directories that are under the control of packages is
always a risky affair. I'm sorry if this resulted in real data loss for
you, but I don't think it's appropriate to hold schroot responsible at an
RC-level for all the ways that things can go wrong if you put symlinks where
directories are expected.
I still think that it should be considered RC, because it could make the user
very very unhappy. If one of the following condiditions was true, I
would agree that it isn't RC:
- schroot provides a way to change the directory with a config option
- schroot detects that a symlink is used, warns the user about
possible data loss, and refuses to start
- schroot doesn't bind-mount /home by default, but only /tmp
- schroot detects that it couldn't find any bind-mount to unmount, and
refuses to clean-up the environment. This is easy to do, I just
changed 10mount to do that:
do_umount_all()
{
echo Mount points:
$LIBEXEC_DIR/schroot-listmounts -m $1
if [ $($LIBEXEC_DIR/schroot-listmounts -m $1 | wc -l) -lt 2 ];
then
echo No mount point found! Something is probably very strange!
exit 1
fi
$LIBEXEC_DIR/schroot-listmounts -m $1 |
[...]
However, schroot doesn't do any of those currently.
BTW, an obvious way to do this without the use of symlinks would be to make
/var/lib/schroot *itself* a bind-mount...
Yeah, that works, but it isn't documented. If you have the bad idea to
use a symlink first, you won't discover this before your /home will be
gone :)
I think you should reconsider setting this as RC. I fear that we will
release with that if it's not RC ...
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
severity 401180 serious thanks * Steve Langasek ([EMAIL PROTECTED]) [061202 02:08]: On Fri, Dec 01, 2006 at 02:29:29PM +0100, Lucas Nussbaum wrote: Symlinking system directories that are under the control of packages is always a risky affair. I'm sorry if this resulted in real data loss for you, but I don't think it's appropriate to hold schroot responsible at an RC-level for all the ways that things can go wrong if you put symlinks where directories are expected. I think schroot should really be fixed here, and should be fixed prior to a stable release. I can imagine lots of people to run into the same situation. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401180: [Buildd-tools-devel] Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
Andreas Barth [EMAIL PROTECTED] writes:
severity 401180 serious
thanks
* Steve Langasek ([EMAIL PROTECTED]) [061202 02:08]:
On Fri, Dec 01, 2006 at 02:29:29PM +0100, Lucas Nussbaum wrote:
Symlinking system directories that are under the control of packages is
always a risky affair. I'm sorry if this resulted in real data loss for
you, but I don't think it's appropriate to hold schroot responsible at an
RC-level for all the ways that things can go wrong if you put symlinks where
directories are expected.
I'd also like to apologise for the data loss you suffered. I didn't
intend for schroot to be used in this way, and this is the result of a
design assumption breaking in a nasty way.
I think schroot should really be fixed here, and should be fixed prior
to a stable release. I can imagine lots of people to run into the same
situation.
The crux of the problem, as I see it, is in schroot-listmounts-main.cc
(main::list_mounts()):
std::string to_find = sbuild::normalname(this-opts-mountpoint);
std::FILE *mntdb = std::fopen(mountfile.c_str(), r);
if (mntdb == 0)
throw error(mountfile, OPEN, strerror(errno));
mntent *mount;
while ((mount = getmntent(mntdb)) != 0)
{
std::string mount_dir(mount-mnt_dir);
if (to_find == / ||
(mount_dir.find(to_find) == 0
(// Names are the same.
mount_dir.size() == to_find.size() ||
// Must have a following /, or not the same directory.
(mount_dir.size() to_find.size()
mount_dir[to_find.size()] == '/'
ret.push_back(mount_dir);
}
Here, we are parsing /proc/mounts using the glibc functions to walk
through all the mounted filesystems, and then unmount all the ones we
find which are under /var/lib/schroot/mounts/$session_id. Finally, we
rm -rf the mountpoint.
Due to the potential for dataloss, schroot-listmounts was written to
ensure that the cleanup would fail if any unmounted filesystems were
not unmounted. However, this cannot cope if you introduce symlinks
into the schroot mount directory path, because this is not recorded in
/proc/mounts or /etc/mtab, and it will always appear as if there are
no filesystems mounted.
One possible solution would be to use realpath(3) to canonicalise the
mount path in schroot-listmounts. This should be quite easy to
implement. to_find can simply be canonicalised; it's a two line fix.
However, I'm wondering if it would be better to canonicalise all paths
at all times in the main code, to prevent anything like this
reoccuring.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
pgpWNCN8v6Ejk.pgp
Description: PGP signature
Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
Package: schroot Version: 1.0.3-1 Severity: critical Justification: causes removal of /home Hi, I am using file chroots. the chroot is usually untared under /var/lib/schroot, however, I wanted to change this to another location (my /var is quite small, and many apps don't like it being full). I couldn't find any way to specify another directory for this, so I just symlinked /var/lib/schroot to another place. However, this caused $LIBEXEC_DIR/schroot-listmounts to be unable to determine that /home, /tmp, etc were still bind-mounted. So do_umount_all in that file exits without error even if my filesystems are still bind-mounted, and my home directory and my /tmp got removed. Example: [EMAIL PROTECTED]:~$ mount [...] /dev/pts on /home/space/schroot/tetch-0128da3c-4a77-4b19-a10b-f60b91536bb5/dev/pts type none (rw,bind) tmpfs on /home/space/schroot/tetch-0128da3c-4a77-4b19-a10b-f60b91536bb5/dev/shm type tmpfs (rw) [EMAIL PROTECTED]:~$ /usr/lib/schroot/schroot-listmounts -m /var/lib/schroot/mount/tetch-0128da3c-4a77-4b19-a10b-f60b91536bb5/ [EMAIL PROTECTED]:~$ schroot-listmounts needs fixing, of course. But it would also be nice to not bind-mount /home by default. There was already a bug causing /home removal (bug #369626). Please note that this bug was discovered in version 1.0.2-1. I cannot confirm that 1.0.3-1 is also affected since I'm still recovering data from a backup. However, I diff'd the two source packages and couldn't find any reason why it wouldn't be affected. Thank you, -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401180: schroot: using a symlink for /var/lib/schroot/mount causes /home and /tmp to be erased
severity 401180 important thanks On Fri, Dec 01, 2006 at 02:29:29PM +0100, Lucas Nussbaum wrote: Package: schroot Version: 1.0.3-1 Severity: critical Justification: causes removal of /home I am using file chroots. the chroot is usually untared under /var/lib/schroot, however, I wanted to change this to another location (my /var is quite small, and many apps don't like it being full). I couldn't find any way to specify another directory for this, so I just symlinked /var/lib/schroot to another place. However, this caused $LIBEXEC_DIR/schroot-listmounts to be unable to determine that /home, /tmp, etc were still bind-mounted. So do_umount_all in that file exits without error even if my filesystems are still bind-mounted, and my home directory and my /tmp got removed. Symlinking system directories that are under the control of packages is always a risky affair. I'm sorry if this resulted in real data loss for you, but I don't think it's appropriate to hold schroot responsible at an RC-level for all the ways that things can go wrong if you put symlinks where directories are expected. BTW, an obvious way to do this without the use of symlinks would be to make /var/lib/schroot *itself* a bind-mount... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
