On Tue, Jan 07, 2014 at 06:45:10PM -0500, Stéphane Graber wrote:
When running pam_loginuid in a container using the user namespaces,
even
uid 0 isn't allowed to set the loginuid property.
This change catches the EACCES from opening loginuid, checks if the
user
is in the host namespace (by comparing the uid_map with the host's one)
and only if that's the case, sets rc to 1.
Should uid_map not exist to be unreadable for some reason, it'll
be
assumed that the process is running on the host's namespace.
The initial reason behind this change was failure to ssh into an
unprivileged container (using a 3.13 kernel and current LXC) when using
a standard pam profile for sshd (which requires success from
pam_loginuid).
I believe this solution doesn't have any drawback and will allow
people
to use unprivileged containers normally. An alternative would be to have
all distros set pam_loginuid as optional but that'd be bad for any of
the other potential failure case which people may care about.
There has also been some discussions to get some of the audit
features
tied with the user namespaces but currently none of that has been merged
upstream and the currently proposed implementation doesn't cover
loginuid (nor is it clear how this should even work when loginuid is set
as immutable after initial write).
Thanks, this looks good to me, except for two points:
- the pam_syslog() call has an inverted conditional (should be rc !=
PAM_IGNORE, rather than rc == PAM_IGNORE).
- if errno != ENOENT, we definitely do *not* want to set rc = PAM_IGNORE,
we want this to be PAM_SESSION_ERR. We want PAM_IGNORE only iff errno ==
ENOENT or errno == EACCES and we're in a userns.
I've addressed these two points here; updated patch is attached.
Any other feedback, or is this ok to commit?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
http://www.debian.org/
slangasek(a)ubuntu.com vorlon(a)debian.org