Debian Bug report logs - #786566
schroot: Should mark bind mounts in the schroot as private

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Tyler Hicks <tyhicks@canonical.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: schroot: Should mark bind mounts in the schroot as private

Date: Fri, 22 May 2015 16:35:56 -0500

[Message part 1 (text/plain, inline)]

Package: schroot
Version: 1.7.2-2
Severity: important
Tags: upstream patch

Dear Maintainer,

Schroot users that have /home/$USER as a separate mount point usually
update the various schroot profiles' fstab to include:

  /home           /home           none    rw,rbind        0       0

That has worked pretty well for many filesystems that would be mounted
at /home/$USER. However, I've recently had a lot of eCryptfs users
reporting issues when using systemd as their init system since systemd
uses shared mount propagation for mounts. The biggest issue is that
/home/$USER is unmounted in the host environment when schroot sessions
are ended due to the unmount events being propagated outside of the
schroot session's subdirectory.

I believe that the best fix is to mark bind mount points, under the
schroot session's subdirectory, as private. Also, rbind mount points
will need to be marked as rprivate.

I'll attach a patch developed against schroot's master git branch (which
should apply to 1.7.2-2) and another developed against the schroot-1.6
branch.

Tyler

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-16-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[master-libexec-mount-make-bind-mounts-private.patch (text/x-diff, attachment)]

[1.6-schroot-mount-make-bind-mounts-private.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Tyler Hicks <tyhicks@canonical.com>

To: 786566@bugs.debian.org

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Wed, 15 Jul 2015 12:47:48 -0500

[Message part 1 (text/plain, inline)]

Hello - I'm sending a friendly poke in hopes that I can get a review for
my proposed patch. The unpatched behavior is a considerable usability
issue on systems that use systemd, schroot, and a filesystem mounted at
/home/$USER. I'd prefer upstream review before I apply the patch to
schroot in Ubuntu. Thanks!

Tyler

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Tyler Hicks <tyhicks@canonical.com>, 786566@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Wed, 15 Jul 2015 19:19:23 +0000

On 15/07/2015 17:47, Tyler Hicks wrote:
> Hello - I'm sending a friendly poke in hopes that I can get a review for
> my proposed patch. The unpatched behavior is a considerable usability
> issue on systems that use systemd, schroot, and a filesystem mounted at
> /home/$USER. I'd prefer upstream review before I apply the patch to
> schroot in Ubuntu. Thanks!

It looks reasonable for you to apply in Ubuntu, but I'm not yet sure if 
it's safe to apply upstream.  It might well be safe for Debian as well, 
but I can't make that determination myself.

Is this safe to use on systems not using systemd?

Does it require a specific version of util-linux for the 
--make-[r]private options to mount?  If so, it probably needs a proper 
functional check for them, and using those as conditionals rather than 
just __linux__.


Regards,
Roger

Message #20 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Tyler Hicks <tyhicks@canonical.com>

To: 786566@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Thu, 16 Jul 2015 15:40:03 -0500

[Message part 1 (text/plain, inline)]

On 2015-07-15 19:19:23, Roger Leigh wrote:
> On 15/07/2015 17:47, Tyler Hicks wrote:
> >Hello - I'm sending a friendly poke in hopes that I can get a review for
> >my proposed patch. The unpatched behavior is a considerable usability
> >issue on systems that use systemd, schroot, and a filesystem mounted at
> >/home/$USER. I'd prefer upstream review before I apply the patch to
> >schroot in Ubuntu. Thanks!
> 
> It looks reasonable for you to apply in Ubuntu, but I'm not yet sure if it's
> safe to apply upstream.  It might well be safe for Debian as well, but I
> can't make that determination myself.

Thank you for the review!

> Is this safe to use on systems not using systemd?

It should be safe on those systems. The mounts that are being bound into
the chroot will most likely already be using private mount propagation
since that is the default mount propagation mode.

> Does it require a specific version of util-linux for the --make-[r]private
> options to mount?  If so, it probably needs a proper functional check for
> them, and using those as conditionals rather than just __linux__.

Good question.

Support for --make-[r]private has been around since the following
commit:

  https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=389fbea536e4308d9475fa2a89e53e188ce8a0e3

It was first released in util-linux 2.13, which happened on 28-Aug-2007:

  https://www.kernel.org/pub/linux/utils/util-linux/v2.13/v2.13-ReleaseNotes

I don't think we need a functional check for something that has been
around for so long.

Tyler

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Tyler Hicks <tyhicks@canonical.com>, 786566@bugs.debian.org

Cc: Roger Leigh <rleigh@codelibre.net>

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Tue, 11 Aug 2015 22:51:33 +0200

Hi,

On Fri, 22 May 2015, Tyler Hicks wrote:
> That has worked pretty well for many filesystems that would be mounted
> at /home/$USER. However, I've recently had a lot of eCryptfs users
> reporting issues when using systemd as their init system since systemd
> uses shared mount propagation for mounts.

Can you point me to some systemd documentation proving your assertion?

I was not able to find the relevant documentation but you appear to be
right. On a wheezy system "/" is not marked as shared while on jessie
it is (you can see that in "cat /proc/self/mountinfo" in the 7th field
with the presence/absence of "shared:X").

Relevant documentation:
$ man proc
https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt

But I don't understand why /home would also inherits from the shared
attribute by default... that said this appears to be the case for me here
too (not with /home in my specific case but another mount point).

> /home/$USER is unmounted in the host environment when schroot sessions
> are ended due to the unmount events being propagated outside of the
> schroot session's subdirectory.
> 
> I believe that the best fix is to mark bind mount points, under the
> schroot session's subdirectory, as private. Also, rbind mount points
> will need to be marked as rprivate.

Would it not be better to mark them as "slave" instead? That way
propagation from the host to the chroot works but not the other
way around?

Also recent mount allow you to specify mount options like "shared",
"slave", "private" so we should respect this choice when
the user has supplied them in the fstab... (or "rshared", "rprivate",
"rslave").

Cheers,

PS: Roger, Tyler forgot to CC you in his last reply, you might want to
check the bug report history.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #30 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Tyler Hicks <tyhicks@canonical.com>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 786566@bugs.debian.org, Roger Leigh <rleigh@codelibre.net>

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Tue, 11 Aug 2015 22:19:59 -0500

[Message part 1 (text/plain, inline)]

On 2015-08-11 22:51:33, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 22 May 2015, Tyler Hicks wrote:
> > That has worked pretty well for many filesystems that would be mounted
> > at /home/$USER. However, I've recently had a lot of eCryptfs users
> > reporting issues when using systemd as their init system since systemd
> > uses shared mount propagation for mounts.
> 
> Can you point me to some systemd documentation proving your assertion?

http://www.freedesktop.org/software/systemd/man/systemd.exec.html

Search for 'Defaults to shared'.

> 
> I was not able to find the relevant documentation but you appear to be
> right. On a wheezy system "/" is not marked as shared while on jessie
> it is (you can see that in "cat /proc/self/mountinfo" in the 7th field
> with the presence/absence of "shared:X").
> 
> Relevant documentation:
> $ man proc
> https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
> 
> But I don't understand why /home would also inherits from the shared
> attribute by default... that said this appears to be the case for me here
> too (not with /home in my specific case but another mount point).

All mounts of my /etc/fstab file are being configured with shared
propagation, not just '/'.

> 
> > /home/$USER is unmounted in the host environment when schroot sessions
> > are ended due to the unmount events being propagated outside of the
> > schroot session's subdirectory.
> > 
> > I believe that the best fix is to mark bind mount points, under the
> > schroot session's subdirectory, as private. Also, rbind mount points
> > will need to be marked as rprivate.
> 
> Would it not be better to mark them as "slave" instead? That way
> propagation from the host to the chroot works but not the other
> way around?

That's a possibility that I considered but I thought it would be best to
simply restore the kernel's default mount propagation mode (private) to
keep from surprising users.

> Also recent mount allow you to specify mount options like "shared",
> "slave", "private" so we should respect this choice when
> the user has supplied them in the fstab... (or "rshared", "rprivate",
> "rslave").

I made sure to preserve that functionality. Only the bind and rbind
mounts in the profile's fstab are being set to private. The mount
utility does not support having bind/rbind and a mount propagation mode
on the same line. If a user wants to set a custom mount propagation
mode, they'd have to do so with a new line in fstab. That's the case
with the mount utility and with my proposed patch to schroot.

> 
> Cheers,
> 
> PS: Roger, Tyler forgot to CC you in his last reply, you might want to
> check the bug report history.

Thanks!

Tyler

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Tyler Hicks <tyhicks@canonical.com>

Cc: 786566@bugs.debian.org, Roger Leigh <rleigh@codelibre.net>

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Wed, 12 Aug 2015 21:08:33 +0200

On Tue, 11 Aug 2015, Tyler Hicks wrote:
> http://www.freedesktop.org/software/systemd/man/systemd.exec.html
> 
> Search for 'Defaults to shared'.

Ok. It's not clear to me that this is related... this is about having
a shared filesystem namespace in which the mount command is called.

How does it translate to the fact that the actual mount point is
tagged as shared? I checked

> All mounts of my /etc/fstab file are being configured with shared
> propagation, not just '/'.

Yeah, me too. But I don't find this documented anywhere.

> > Would it not be better to mark them as "slave" instead? That way
> > propagation from the host to the chroot works but not the other
> > way around?
> 
> That's a possibility that I considered but I thought it would be best to
> simply restore the kernel's default mount propagation mode (private) to
> keep from surprising users.

Actually the root of the chroot is already marked as private, cf do_mount()
in /etc/schroot/setup.d/10mount

    # Mark this mountpoint as private; some systems have / as a shared mountpoint.
    # As an example, assume /home/m/ch is the chroot directory.
    # schroot will mount -o bind /home/m/ch to /var/lib/schroot/mount/ch-123
    # Afterwards, it will bind-mount /dev to /var/lib/schroot/mount/ch-123.
    # With shared mountpoints, that mount will also show up in the original
    # /home/m/ch. This is a problem once schroot mounted /home: the following
    # mount of /tmp will show up in /var/lib/schroot/mount/ch-123/tmp,
    # /home/m/ch/tmp and /home/m/ch/home/m/ch/tmp (!), which leads to failure
    # on unmounting.
    if [ "$(uname -s)" = "Linux" ]; then
      mount --make-private "$3"
    fi

> > Also recent mount allow you to specify mount options like "shared",
> > "slave", "private" so we should respect this choice when
> > the user has supplied them in the fstab... (or "rshared", "rprivate",
> > "rslave").
> 
> I made sure to preserve that functionality. Only the bind and rbind
> mounts in the profile's fstab are being set to private. The mount
> utility does not support having bind/rbind and a mount propagation mode
> on the same line. If a user wants to set a custom mount propagation
> mode, they'd have to do so with a new line in fstab. That's the case
> with the mount utility and with my proposed patch to schroot.

That's no longer the case. As I said, mount now accepts such options
(even for bind mount), cf man mount:

  Since util-linux 2.23 the  mount  command  allows  to  use  several
  propagation  flags together  and also together with other mount
  operations.  This feature is EXPERIMENTAL.  The propagation flags are
  applied by additional mount(2) syscalls  when  the  preceding mount
  operations were successful.  Note that this use case is not atomic.  It
  is possible to specify the propagation flags in fstab(5)  as  mount
  options  (private,  slave, shared, unbindable, rprivate, rslave,
  rshared, runbindable).

I just tested this by changing one /etc/schroot/*/fstab to add a "slave"
option on a bind mount and it worked as expected.

Thus I believe that you should not call mount --make-private if one of
those option is set in the fstab file.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #40 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Tyler Hicks <tyhicks@canonical.com>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 786566@bugs.debian.org, Roger Leigh <rleigh@codelibre.net>

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Tue, 27 Oct 2015 17:36:19 -0500

[Message part 1 (text/plain, inline)]

On 2015-08-12 21:08:33, Raphael Hertzog wrote:
> On Tue, 11 Aug 2015, Tyler Hicks wrote:
> > > Also recent mount allow you to specify mount options like "shared",
> > > "slave", "private" so we should respect this choice when
> > > the user has supplied them in the fstab... (or "rshared", "rprivate",
> > > "rslave").
> > 
> > I made sure to preserve that functionality. Only the bind and rbind
> > mounts in the profile's fstab are being set to private. The mount
> > utility does not support having bind/rbind and a mount propagation mode
> > on the same line. If a user wants to set a custom mount propagation
> > mode, they'd have to do so with a new line in fstab. That's the case
> > with the mount utility and with my proposed patch to schroot.
> 
> That's no longer the case. As I said, mount now accepts such options
> (even for bind mount), cf man mount:
> 
>   Since util-linux 2.23 the  mount  command  allows  to  use  several
>   propagation  flags together  and also together with other mount
>   operations.  This feature is EXPERIMENTAL.  The propagation flags are
>   applied by additional mount(2) syscalls  when  the  preceding mount
>   operations were successful.  Note that this use case is not atomic.  It
>   is possible to specify the propagation flags in fstab(5)  as  mount
>   options  (private,  slave, shared, unbindable, rprivate, rslave,
>   rshared, runbindable).
> 
> I just tested this by changing one /etc/schroot/*/fstab to add a "slave"
> option on a bind mount and it worked as expected.
> 
> Thus I believe that you should not call mount --make-private if one of
> those option is set in the fstab file.

Thanks. I've attached patches which do what you suggested.

Tyler

[master-libexec-mount-make-bind-mounts-private.patch (text/x-diff, attachment)]

[1.6-schroot-mount-make-bind-mounts-private.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: Brian May <bam@debian.org>

Cc: Michael Biebl <biebl@debian.org>, debian-devel@lists.debian.org, debian-kernel@lists.debian.org, pkg-systemd-maintainers@lists.alioth.debian.org, 786566@bugs.debian.org

Subject: Re: broken mount behaviour on jessie

Date: Mon, 1 Feb 2016 12:45:16 +0100

On Mon, 01 Feb 2016, Brian May wrote:

> Michael Biebl <biebl@debian.org> writes:
> 
> > Have you tried the patch in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566
> 
> I see two patches here - one patch applies easy enough to schroot -
> 1.6-schroot-mount-make-bind-mounts-private.patch
> 
> I am not sure what the
> master-libexec-mount-make-bind-mounts-private.patch is for, it seems to
> patch files not in schroot but has references to schroot files.
> 
> Do I need the 2nd patch or is the 1st one sufficient?

The first seems to have helped significantly for schroot.

It doesn't, of course, fix the inherent brokeness that can be observed
by the sysadmin doing other mount things.

Also, it is still racy, as it first mounts the target and afterwards
modifies flags.

Cheers,
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Message #50 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: 786566@bugs.debian.org

Cc: control@bugs.debian.org

Subject: this is affecting us

Date: Wed, 30 Nov 2016 14:57:07 +0000

severity 786566 serious
thanks

This schroot issue is affecting our debian.org porterboxes, and it
affects other users (e.g. torproject.org build environment) where more
than one chroot is being used at a time.

We really should fix this for stretch.
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Message #59 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Brian May <bam@debian.org>

To: Peter Palfrader <weasel@debian.org>, 786566@bugs.debian.org

Subject: Re: Bug#786566: this is affecting us

Date: Mon, 5 Dec 2016 18:12:50 +1100

On Wed, Nov 30, 2016 at 02:57:07PM +0000, Peter Palfrader wrote:
> severity 786566 serious
> thanks
> 
> This schroot issue is affecting our debian.org porterboxes, and it
> affects other users (e.g. torproject.org build environment) where more
> than one chroot is being used at a time.
> 
> We really should fix this for stretch.

Does this bug really warrant being serious? As it is we risk having this
package removed from testing. Is this justified?
-- 
Brian May <bam@debian.org>

Message #64 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: Brian May <bam@debian.org>

Cc: 786566@bugs.debian.org

Subject: Re: Bug#786566: this is affecting us

Date: Mon, 5 Dec 2016 07:38:35 +0000

On Mon, 05 Dec 2016, Brian May wrote:

> On Wed, Nov 30, 2016 at 02:57:07PM +0000, Peter Palfrader wrote:
> > severity 786566 serious
> > thanks
> > 
> > This schroot issue is affecting our debian.org porterboxes, and it
> > affects other users (e.g. torproject.org build environment) where more
> > than one chroot is being used at a time.
> > 
> > We really should fix this for stretch.
> 
> Does this bug really warrant being serious? As it is we risk having this
> package removed from testing. Is this justified?

It's a serious bug that makes it break in many cases, requiring the
sysadmin to clean up and/or reboot the system.  Whether or not it's RC
in the end is the decision of the release team, but this severity was
set after discussing this on #debian-release.

-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Message #69 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Peter Palfrader <weasel@debian.org>

To: "Wesley W. Terpstra" <terpstra@debian.org>

Cc: debian-admin@lists.debian.org, 786566@bugs.debian.org

Subject: Re: Fwd: Cannot remove old schroots

Date: Sun, 18 Dec 2016 08:51:30 +0000

On Sat, 17 Dec 2016, Wesley W. Terpstra wrote:

> I cannot remove these two chroots:
> 
> terpstra@eller:~$ schroot -c sid-mips64el-mlton -e
> E: 10mount: umount: /var/lib/schroot/mount/sid-mips64el-mlton/dev/pts:
> target is busy
> E: 10mount:         (In some cases useful info about processes that
> E: sid-mips64el-mlton: Chroot setup failed: stage=setup-stop
> terpstra@eller:~$ schroot -c sid-mipsel-mlton -e
> E: 10mount: umount: /var/lib/schroot/mount/sid-mipsel-mlton/dev/pts:
> target is busy
> E: 10mount:         (In some cases useful info about processes that
> E: 10mount:          use the device is found by lsof(8) or fuser(1).)
> E: sid-mipsel-mlton: Chroot setup failed: stage=setup-stop
> 
> Please feel free to reclaim this disk space.

I think this is #786566 again.  Cc'ing it this time.

-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Message #74 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Brian May <bam@debian.org>

To: Peter Palfrader <weasel@debian.org>

Cc: 786566@bugs.debian.org

Subject: Re: Bug#786566: this is affecting us

Date: Thu, 05 Jan 2017 20:23:13 +1100

Peter Palfrader <weasel@debian.org> writes:

> It's a serious bug that makes it break in many cases, requiring the
> sysadmin to clean up and/or reboot the system.  Whether or not it's RC
> in the end is the decision of the release team, but this severity was
> set after discussing this on #debian-release.

Is anything being done to fix this? What is the hold up? Apparently
there is a patch for this RC bug and the other RC bug #817236.

It is kind of looking like stretch will get released without schroot
support, or any packages that depend on it. Maybe time to forgot schroot
and look for alternatives???
-- 
Brian May <bam@debian.org>

Message #79 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Brian May <bam@debian.org>, 786566@bugs.debian.org, Peter Palfrader <weasel@debian.org>

Subject: Re: Bug#786566: this is affecting us

Date: Thu, 5 Jan 2017 10:08:02 +0000

On 05/01/17 09:23, Brian May wrote:
> Peter Palfrader <weasel@debian.org> writes:
>
>> It's a serious bug that makes it break in many cases, requiring the
>> sysadmin to clean up and/or reboot the system.  Whether or not it's RC
>> in the end is the decision of the release team, but this severity was
>> set after discussing this on #debian-release.
>
> Is anything being done to fix this? What is the hold up? Apparently
> there is a patch for this RC bug and the other RC bug #817236.

I'm not personally working on any fix in schroot, since it's not an 
schroot bug.

> It is kind of looking like stretch will get released without schroot
> support, or any packages that depend on it. Maybe time to forgot schroot
> and look for alternatives???

schroot is not responsible for setting up device nodes in a 
debootstrapped chroot.  We expect them to be set up correctly.  This 
isn't a Debian-specific constraint; we expect all chroots of any sort to 
be in a sane and directly usable state.

schroot's requirements are not any different here from that of the basic 
chroot(8).  Is chroot(8) equally broken here?  The mounts and other 
features schroot offers on top of that are entirely optional, and 
implementation wise is nothing more than a wrapper around chroot(2) to 
perform exactly the same job as chroot(8) with some sudo-like PAM 
authentication and authorisation.

While we could add additional mounts to the schroot fstab templates, 
it's important to understand that this is optional functionality, and 
has always been optional.  It's not a mechanism for working around 
external breakage.

Looking for alternatives to schroot is entirely your choice, but 
breaking basic system-level functionality which has been working for 
over two decades, and used for over 11 years by schroot, is I think 
something which needs careful consideration.  I'm prepared to do some 
work to ensure that schroot interoperates with contemporary systems, but 
working around breakage like this is perhaps a step too far.


Regards,
Roger

Message #84 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Brian May <bam@debian.org>, 786566@bugs.debian.org, Peter Palfrader <weasel@debian.org>

Subject: Re: Bug#786566: this is affecting us

Date: Thu, 5 Jan 2017 17:12:51 +0000

On 05/01/17 10:08, Roger Leigh wrote:
>
>
> On 05/01/17 09:23, Brian May wrote:
>> Peter Palfrader <weasel@debian.org> writes:
>>
>>> It's a serious bug that makes it break in many cases, requiring the
>>> sysadmin to clean up and/or reboot the system.  Whether or not it's RC
>>> in the end is the decision of the release team, but this severity was
>>> set after discussing this on #debian-release.
>>
>> Is anything being done to fix this? What is the hold up? Apparently
>> there is a patch for this RC bug and the other RC bug #817236.
>
> I'm not personally working on any fix in schroot, since it's not an
> schroot bug.
>
>> It is kind of looking like stretch will get released without schroot
>> support, or any packages that depend on it. Maybe time to forgot schroot
>> and look for alternatives???
>
> schroot is not responsible for setting up device nodes in a
> debootstrapped chroot.  We expect them to be set up correctly.  This
> isn't a Debian-specific constraint; we expect all chroots of any sort to
> be in a sane and directly usable state.
>
> schroot's requirements are not any different here from that of the basic
> chroot(8).  Is chroot(8) equally broken here?  The mounts and other
> features schroot offers on top of that are entirely optional, and
> implementation wise is nothing more than a wrapper around chroot(2) to
> perform exactly the same job as chroot(8) with some sudo-like PAM
> authentication and authorisation.
>
> While we could add additional mounts to the schroot fstab templates,
> it's important to understand that this is optional functionality, and
> has always been optional.  It's not a mechanism for working around
> external breakage.
>
> Looking for alternatives to schroot is entirely your choice, but
> breaking basic system-level functionality which has been working for
> over two decades, and used for over 11 years by schroot, is I think
> something which needs careful consideration.  I'm prepared to do some
> work to ensure that schroot interoperates with contemporary systems, but
> working around breakage like this is perhaps a step too far.

Very sorry, replying to the wrong ticket here.  Got confused with #817236.

For this specific issue with mount options, I've been following along 
but so far the discussion and proposed patches in this bug haven't 
reached a definitive conclusion with a consensus, so I'm waiting on an 
informed decision before I apply anything upstream.  I don't myself have 
the expertise to judge what the right action is here, so I'll defer to 
others for what's best.

Speaking frankly, I'm appalled that such gratuitous breakage through 
incompatible changes to the functioning of the base system was and is 
considered at all acceptable.  There's over 20 years of software 
development and admin experience on Debian, 11 for schroot, and there's 
a lot of code, and a lot of sysadmin-related scripting and expectations 
which makes assumptions about how mount(2) and mount(8) will behave. 
schroot is just one tool amongst many which expects them to work in the 
traditional, documented and most of all portable way.  Changing 
fundamental default system-wide behaviour on a whim is not what I would 
expect for a mature and established system.  I'd expect rather more 
considered and measured incremental change, which is something I've 
tried to pay proper attention to in my own work.  As an opt-in option 
for certain mounts, it would be fine, but enforcing it system wide is 
somewhat cavalier and inconsiderate of the multi-decade established 
semantics which we expect.  This significant change in attitude is one 
of the factors behind my no longer actively using or developing on 
Debian.  Like it or not, it's become a mature system, and that brings 
with it some responsibility toward backward compatibility even when we 
might want to rip it all out and start over with something new and exciting.

Too late to fix that now, so I'll consider applying upstream whatever 
makes most sense.  However, I must stress that schroot must remain 
portable to non-systemd-Linux, GNU/Hurd, GNU/kFreeBSD and FreeBSD, and 
any patches must not break this support.


Roger

Message #89 received at 786566@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Tyler Hicks <tyhicks@canonical.com>, 786566@bugs.debian.org, Raphaël Hertzog <hertzog@debian.org>

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Tue, 10 Jan 2017 17:32:23 +0000

On Wed, 15 Jul 2015 at 12:47:48 -0500, Tyler Hicks wrote:
> Hello - I'm sending a friendly poke in hopes that I can get a review for
> my proposed patch.

This patch appears to have been applied in schroot 1.6.10-3.
However, it was marked as fixing #761435, which was previously closed
as "user mistake" (misconfiguration).

Raphaël, did you mix up the bug numbers here? I suspect you meant to
close #786566 instead?

Thanks,
    S

Message #94 received at 786566-done@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Simon McVittie <smcv@debian.org>

Cc: Tyler Hicks <tyhicks@canonical.com>, 786566-done@bugs.debian.org

Subject: Re: Bug#786566: schroot: Should mark bind mounts in the schroot as private

Date: Wed, 11 Jan 2017 11:33:40 +0100

Version: 1.6.10-3

Hi Simon,

On Tue, 10 Jan 2017, Simon McVittie wrote:
> On Wed, 15 Jul 2015 at 12:47:48 -0500, Tyler Hicks wrote:
> > Hello - I'm sending a friendly poke in hopes that I can get a review for
> > my proposed patch.
> 
> This patch appears to have been applied in schroot 1.6.10-3.
> However, it was marked as fixing #761435, which was previously closed
> as "user mistake" (misconfiguration).
> 
> Raphaël, did you mix up the bug numbers here? I suspect you meant to
> close #786566 instead?

Yes, doing it now. Thanks for the notice!

Cheres,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Send a report that this bug log contains spam.