Bug#599399: Incorrect effective groups when logging in with NIS and pubkey auth

[Arto Jantunen <viiru@debian.org>]

Russ Allbery <rra@debian.org> writes:

> Arto Jantunen <viiru@debian.org> writes:
>
>> On current squeeze when I login using pubkey auth to a machine that uses
>> NIS, I end up with only the primary group and none of the others that my
>> user is a member of. I can add the others using newgrp (without any
>> passwords). If I disable pubkey and login via password (adding -O
>> PubkeyAuthentication=no to the command line), the rest of the groups
>> appear. None of the involved groups exist in /etc/group, they all come
>> through NIS.
>
>> This may very well be a bug in PAM or NIS, but I can't get a good enough
>> handle on the problem to be able to tell. I'm using the fact that an ssh
>> option changes the behavior as justification for filing this against it..
>
> I suspect it's related to PAM.  The PAM calling sequence changes a lot
> based on whether you use a password or use public key.
>
> The part of the PAM stack responsible for setting up supplemental groups
> is the session stack, and I believe it's done by pam_unix.  When you log
> in with a password, ssh will also call the auth stack and the account
> stack; when you log in with public key, it will only call the session
> stack (and perhaps setcred; that part is always confused).
>
> I suspect that for some reason your supplemental group behavior is
> changing based on what parts of the PAM stack are run.  One simple
> explanation for this would be if your PAM stack involves branches that
> skip around modules under various conditions, which could cause things to
> be run in the password case and not in the pubkey case.

PAM was my first guess as well, but I don't have any concrete knowledge about
the sequence changes involved here (my understanding of PAM is fairly
superficial, and also outdated). Are you confident enough about your theory
to reassign this bug to PAM?

-- 
Arto Jantunen