[Pam-developers] [PATCH] pam_loginuid: Ignore failure in user namespaces
Steve Langasek
vorlon at debian.org
Tue Jan 7 22:12:57 UTC 2014
Hi Stéphane,
On Fri, Dec 06, 2013 at 07:47:34PM -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.
This change looks generally correct to me; since it detects the specific
case where we're EACCES on /proc/self/loginuid due to userns, and treats
this one case as a non-error, it's safer than making the admin change the
PAM config to ignore all errors from the module.
Upon review, however, I do have one concern with the patch, which is that
the module will return PAM_SUCCESS for this case. I think it would be
preferable to return PAM_IGNORE, so that we can distinguish between
"loginuid set successfully" and "loginuid not set, but this is expected".
In that case, the ENOENT case should also be handled as PAM_IGNORE rather
than PAM_SUCCESS.
--
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 at ubuntu.com vorlon at debian.org
> 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).
> ---
> modules/pam_loginuid/pam_loginuid.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/modules/pam_loginuid/pam_loginuid.c b/modules/pam_loginuid/pam_loginuid.c
> index a903845..977cbea 100644
> --- a/modules/pam_loginuid/pam_loginuid.c
> +++ b/modules/pam_loginuid/pam_loginuid.c
> @@ -53,11 +53,26 @@ static int set_loginuid(pam_handle_t *pamh, uid_t uid)
> {
> int fd, count, rc = 0;
> char loginuid[24], buf[24];
> + char uid_map[256];
>
> count = snprintf(loginuid, sizeof(loginuid), "%lu", (unsigned long)uid);
> fd = open("/proc/self/loginuid", O_NOFOLLOW|O_RDWR);
> if (fd < 0) {
> - if (errno != ENOENT) {
> + if (errno == EACCES) {
> + rc = 1;
> + fd = open("/proc/self/uid_map", O_RDONLY);
> + if (fd >= 0) {
> + count = pam_modutil_read(fd, uid_map, sizeof(uid_map));
> + if (strncmp(uid_map, " 0 0 4294967295\n",
> + count) != 0)
> + rc = 0;
> + close(fd);
> + }
> + if (rc == 1)
> + pam_syslog(pamh, LOG_ERR,
> + "Cannot open /proc/self/loginuid: Permission denied");
> + }
> + else if (errno != ENOENT) {
> rc = 1;
> pam_syslog(pamh, LOG_ERR,
> "Cannot open /proc/self/loginuid: %m");
> --
> 1.8.5.1
>
> _______________________________________________
> Pam-developers mailing list
> Pam-developers at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/pam-developers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.fedorahosted.org/pipermail/pam-developers/attachments/20140107/90615c86/attachment.sig>
More information about the Pam-developers
mailing list