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

[Kai Krakow]

Lennart Poettering <lennart at poettering.net> schrieb:

> 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.

Then the question is: Why or what does try to start a user session in the 
first place? I don't think KDE does this as it's not there yet (at least in 
KDE 4.x). And I didn't enable a user at ...service (but shouldn't it work then 
when started from the normal service startups in systemd).

I don't consider this a bug, but my main problem with this is I have no idea 
how to track that down.

>> 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...

If it doesn't hurt either, I just let it the way it is. There was just this 
idea it could be related to the problem. But from your words I guess: nope.

>> 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.

Maybe just turn off the RT_FIFO feature in the kernel for the time being?

> Not sure what else I can suggest...

I appreciate that you answered although this was pretty old. Good to know 
thinks don't become forgotten, just take time. ;-)

-- 
Replies to list only preferred.