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

[Russ Allbery <rra@debian.org>]

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.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>