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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org