Re: [PATCH][RESEND 2] Revert "AUDIT: Allow login in non-init namespaces"

On Thursday, January 08, 2015 05:44:48 PM Calvin Owens wrote: > This reverts 543bc6a1a987 "AUDIT: Allow login in non-init namespaces". > > This commit incorrectly assumes that libpam treats -ECONNREFUSED as > an indicator that audit is disabled, and -EPERM or any other error > as a fatal error that prevents the login from continuing. > > The opposite is in fact true: -EPERM allows the login to continue, > and -ECONNREFUSED causes it to refuse the login. This behavior has > been unchanged in upstream linux-pam since at least 2008. > > Reverting this change allows libpam to again work as expected in > non-init user namespaces. > > Signed-off-by: Calvin Owens <calvinowens(a)fb.com&gt; > Cc: stable(a)vger.kernel.org > --- > Relevant code in linux-pam: > https://urldefense.proofpoint.com/v1/url?u=https://git.fedorahosted.org/c... > > kernel/audit.c | 12 +----------- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/kernel/audit.c b/kernel/audit.c > index 80983df..656e8ce 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -640,18 +640,8 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 > msg_type) int err = 0; > > /* Only support initial user namespace for now. */ > - /* > - * We return ECONNREFUSED because it tricks userspace into thinking > - * that audit was not configured into the kernel. Lots of users > - * configure their PAM stack (because that's what the distro does) > - * to reject login if unable to send messages to audit. If we return > - * ECONNREFUSED the PAM stack thinks the kernel does not have audit > - * configured in and will let login proceed. If we return EPERM > - * userspace will reject all logins. This should be removed when we > - * support non init namespaces!! > - */ > if (current_user_ns() != &init_user_ns) > - return -ECONNREFUSED; > + return -EPERM; While I haven't had reason to test this code lately, last I knew it was working, what problems are you seeing Calvin? Also, with what distribution?

-- paul moore www.paul-moore.com