[systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted

[Lennart Poettering]

On Tue, 10.02.15 08:42, Kai Krakow (hurikhan77 at gmail.com) wrote:

> >> Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session):
> >> Could not set limit for 'memlock': Operation not permitted
> >> Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session):
> >> Could not set limit for 'nice': Operation not permitted
> >> Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session):
> >> Could not set limit for 'rtprio': Operation not permitted
> >> Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message()
> >> failed: Operation not permitted
> >> Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning
> >> /usr/lib/systemd/systemd: Operation not permitted
> >> 
> >> Is it meaningless? Do I have to worry? Or which configuration do I miss?
> > 
> > Hmm, this is certainly weird. It indicates some issue with your PAM
> > setup maybe? Do you have SELinux enabled? Is this in some container or so?
> 
> This is a Gentoo box, plain hardware. My pam configuration looks right. When 
> I run "systemd --user" manually through strace, I see missing permissions on 
> cgroups. But I almost guess this is intended if running from an already 
> existing user session.

Yeah, --user instances of systemd don't get access to the controller
attributes of the cgroup tree, and that's intended.

> I don't use SELinux or similar security policies, just plain Linux security 
> policy as it is default in Gentoo. But strangely systemd gives me on boot:
> 
> systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR 
> +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP 
> +BLKID +ELFUTILS +KMOD +IDN)
> 
> I don't know why smack is enabled... It's not in my kernel and isn't set as 
> a feature to compile in the ebuild. But I'm not sure if it would make a 
> difference for this problem.

Well, turn it off during build-time if you don't want it. Use
--disable-smack. It is enabled by default, since all features we
consider stable are enabled by default unless their library
dependencies are missing. Since SMACK so far didn't require any
library it hence is effectively always on unless you explicitly turn
it off...

> 
> I suppose for the same reason, rtkit-daemon cannot give RT priority to 
> itself...

This is unrelated. The kernel RT cgroup API is really just awfully
broken, ignore this.

Not sure what else I can suggest...

Lennart

-- 
Lennart Poettering, Red Hat