[buildd-tools-devel] Bug#727712: Bug#727712: Supplementary groups taken from the host system instead of the chroot

[Roger Leigh]

tags 727712 + wishlist
thanks

On Fri, Oct 25, 2013 at 06:22:55PM +0200, Gaudenz Steinlin wrote:
> Supplememntary groups are initilized with initgroups before switching to
> the chroot. This means that groups are initialize according to the group
> database on the host system instead of the chroot. But groups should be
> initialized according to the group database inside the chroot.

They probably should be, but they can't.  At least, they can't at
present, and unless a proper solution to the problem can be found,
they won't be for the forseeable future.

The rationale:
We can't do *any* system database lookups which use NSS after the
chroot() call.  It's not safe.  We can't risk
- using cached data
- triggering an NSS module load in the chroot

If we trigger a module load:
- it might be from an incompatible glibc version
- it might be from a different architecture (we support different
  architectures inside the chroot via qemu-user-static)
- the chroot might be from a completely different operating system
  (we support kernel personality switching) without any NSS support
- we may have dropped privs which allow lookups to work or disabled
  networking entirely which would break LDAP
- schroot works on several non-Linux non-glibc platforms; what would
  happen on these?

As a result, we took the decision to always do *all* NSS lookups
outside the chroot, and copy in the NSS databases to guarantee
consistency.  It's suboptimal, but it's safe under almost all
circumstances.  I'm certainly sympathetic to the fact that this
isn't ideal, and I'd be open to change the behaviour for 1.7.x, but
we do need a means of making this stuff work portably and reliably
without causing program crashes or security problems if NSS
screws up.

> The attached patch moves the group initialization after the chroot call.
> It is done against 1.6.5, but should also apply to 1.7.1 modulo the
> changed file location.

Thanks for taking the time to make the patch, but I can't apply it at
this time.

> But #685512 is a related but orthogonal problem. It might make sense to
> also move the pam initialization to after the chroot call to use the pam
> configuration inside the chroot. Otherwise setting groups with
> pam_groups won't because they get overwritten by initgroups (as it's the
> case right now as far as I understand the code). But setting groups with
> pam_groups seems like a corner case to me.

We have the same deal with PAM as well.  In fact, it's often worse
since these can invoke anything and trigger loading of all sorts of
additional libraries.  Given the architecture/personality mismatching,
this just can't work in a reliable manner.  This has caused some
complaints in the past for similar reasons to NSS, but the underlying
rationale is pretty much the same.

As for NSS, I'd be open to changing things if there was a clear
solution to the problems.


Kind regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800