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.

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.

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.

Gaudenz

tags 727712 + wishlist
thanks
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.

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

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