diff options
author | Stéphane Graber <stgraber@ubuntu.com> | 2014-01-17 18:24:16 -0500 |
---|---|---|
committer | Steve Langasek <vorlon@debian.org> | 2014-01-18 20:23:46 -0800 |
commit | 2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a (patch) | |
tree | 01254080abeb52d6861e3f54c190fe70e886dfa0 /modules/pam_limits/pam_limits.c | |
parent | fbc65c39d6853af268c9a093923afc876d0b138e (diff) | |
download | pam-2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a.tar.gz pam-2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a.tar.bz2 pam-2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a.zip |
pam_loginuid: Always return PAM_IGNORE in userns
The previous patch to support user namespaces works fine with containers
that are started from a desktop/terminal session but fails when dealing
with containers that were started from a remote session such as ssh.
I haven't looked at the exact reason for that in the kernel but on the
userspace side of things, the difference is that containers started from
an ssh session will happily let pam open /proc/self/loginuid read-write,
will let it read its content but will then fail with EPERM when trying
to write to it.
So to make the userns support bullet proof, this commit moves the userns
check earlier in the function (which means a small performance impact as
it'll now happen everytime on kernels that have userns support) and will
set rc = PAM_IGNORE instead of rc = PAM_ERROR.
The rest of the code is still executed in the event that PAM is run on a
future kernel where we have some kind of audit namespace that includes a
working loginuid.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Signed-off-by: Steve Langasek <vorlon@debian.org>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Diffstat (limited to 'modules/pam_limits/pam_limits.c')
0 files changed, 0 insertions, 0 deletions