[Devel] [PATCH 3/3] hooks_ct: trick PAM to not bail out in loginuid failures

[Glauber Costa]

>From pam_loginuid manpage: "The pam_loginuid module sets the loginuid process
attribute for the process that was authenticated.  This is necessary for
applications to be correctly audited"

The audit subsystem is not namespace aware, and it is likely to be a long time
before it becomes - if ever. There isn't still consensus in the comunity about
whether or not it makes sense, and if it does, how to implement it.

When authenticating, however, writes to the loginuid will fail under user
namespaces, and login programs like ssh will fail to work. One solution that
does not involve recompiling the kernel with audit disabled, or rebooting into
a command line disabled state, is to bind mount the permit module - that
basically permits anything - into the loginuid module.

This is not distribution specific - aside from the right path - so we apply for
all distros, before we go do the fixup scripts.

Signed-off-by: Glauber Costa <glommer at openvz.org>
---
 src/lib/hooks_ct.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/src/lib/hooks_ct.c b/src/lib/hooks_ct.c
index f769865..a4f9425 100644
--- a/src/lib/hooks_ct.c
+++ b/src/lib/hooks_ct.c
@@ -288,6 +288,50 @@ static int apply_fixups(vps_handler *h, envid_t veid, const char *root, dist_act
 	char buf[STR_SIZE];
 	int runlevels[] = { 3, 5 }; /* where to apply the fixups */
 	unsigned int i;
+	char *pampaths[] = { "/lib/security/", "/lib64/security",  /* centos, suse, debian */
+			     "/lib/x86_64-linux-gnu/security/", /* ubuntu */
+			     "/lib/i386-linux-gnu/security/" /* ubuntu */
+			   };
+
+	/*
+	 * From pam_loginuid manpage: "The pam_loginuid module sets the
+	 * loginuid process attribute for the process that was authenticated.
+	 * This is necessary for applications to be correctly audited"
+	 *
+	 * The audit subsystem is not namespace aware, and it is likely to be a
+	 * long time before it becomes - if ever. There isn't still consensus
+	 * in the comunity about whether or not it makes sense, and if it does,
+	 * how to implement it.
+	 *
+	 * When authenticating, however, writes to the loginuid will fail under
+	 * user namespaces, and login programs like ssh will fail to work. One
+	 * solution that does not involve recompiling the kernel with audit
+	 * disabled, or rebooting into a command line disabled state, is to
+	 * bind mount the permit module - that basically permits anything -
+	 * into the loginuid module.
+	 *
+	 * This is not distribution specific - aside from the right path - so
+	 * we apply for all distros, before we go do the fixup scripts.
+	 */
+	for (i = 0; i < ARRAY_SIZE(pampaths); i++) {
+		struct stat st;
+		char buf_orig[STR_SIZE];
+
+		snprintf(buf, sizeof(buf), "%s%s/pam_loginuid.so",
+			 root, pampaths[i]);
+
+		if (stat(buf, &st))
+			continue;
+
+		snprintf(buf_orig, sizeof(buf_orig), "%s%s/pam_permit.so",
+			 root, pampaths[i]);
+
+		if ((stat(buf_orig, &st)) || (mount(buf_orig, buf, "", MS_BIND, 0) < 0))
+			logger(-1, errno,
+			"Cannot overwrite pam_loginuid.so. Container will start, but"
+			"login-based programs like ssh may not work");
+		break;
+	}
 
 	/* Distributions that don't need the fixup will can stop right here */
 	if (!actions || !actions->ct_fixup)
-- 
1.7.11.7