pam_systemd reduction

[Werkov]

Functions of pam_systemd

• talks to systemd-logind
  • creates a session scope unit (lifecycle, cgrp resource control,...)
  • registers a session at logind
  • starts user@.service
• sets up environment XDG_SESSION_ID and XDG_RUNTIME_DIR

Problem

• pam_systemd is often invoked in situations where full-fledged session is not needed or even misleading
  • unneedded:
  • cron sessions where jobs runs under non-privileged UID and user@.service or even communication with logind is excessive
  • why misleading:
  • process is migrated out of original cgroup and systemd treats it as a member of a different unit (service processes migrate from system.slice to user.slice)
    • lifecycle mismatches (logind.conf:KillUserProcesses=)
    • resource control (misattributed consumption or limits)
• list of bugs historically encountered and worked around
  • runuser/sudo not possible before autoinstall is finished (systemd-user-sessions.service ordering)
  • frequent sudo calls increase resource usage
  • unexpected change of cgroup (due to su(do) in service scripts), confusing for limits configuration (and killing to some extent)
• lots of cronjobs, unnecessarily many sessions created (and leaked)

Approximate solution

• when sudo is called from an existing user session, no nesting happens because logind (other end of pam_systemd) detects it and bails out

Solution

• Some of the involved utilites already ship two PAM stack configs for interactive and non-interactive sessions.
• Non-internactive sessions align with cases where pam_systemd is superfluous.
• So we only need to split the common-session include to distinguish the two cases.
• Demo with accompanying packages in OBS (su and crond would also need the switch to common-session-noninteractive).

[thkukuk]

What do our systemd maintainers say about this? And upstream systemd?

We did need quite some time until we found a config where pam_systemd does really work. I double checked, and our competitors are still doing it the same way as we do currently.

I'm strictly against going a separate way not following upstream and everybody else. And what you describe as "misleading" is in my opinion the correct thing to do.

@fbuihuu was this discussed with you?

[Werkov]

What do our systemd maintainers say about this?

Here's a thread (sorry to the public audience, it's an internal link).

And upstream systemd?

systemd doesn't ship distro's PAM configs, thus I didn't ask. (Part of the problem was solved and reverted later.)

We did need quite some time until we found a config where pam_systemd does really work.

I know. Although, "finding a config" also meant workarounds when a service used su(do) and its processes ended up elsewhere. The proposed change allows getting rid of the workarounds. And if someone really wants the session, they can invoke interactively.

I double checked, and our competitors are still doing it the same way as we do currently.

I don't understand the argument by competition. Admittedly, the idea I propose comes from Debian distro, i.e. Ubuntu inherits that as well.

I'm strictly against going a separate way not following upstream and everybody else.

These PAM configs are distro-specific anyway. There's beauty in diversity :-)

Or do you suggest moving and unifying PAM configs in PAM upstream itself?

And what you describe as "misleading" is in my opinion the correct thing to do.

I didn't want to present this as an opinion. It's a technical problem where service processes are extracted into user sessions with described consequences. How else could it be solved?

In my opinion, it's incorrect to downgrade privileges with sudo in a systemd service code. Regardless of that the proposal allows either behavior if a user wants such services.

[thkukuk]

Another thing I don't understand: you make the differentiation between interactive or non interactive. But your problems should either exist always with this tools or not. I fail to see why interactive vs. non interactive should make a difference. If at all, it should be depending on login sessions (so login, sshd, xdm, gdm, sddm, ...) or not (sudo, runuser, su, ...). So we would need something like "postlogin" from Fedora. That's on the TODO list anyways, as this is needed for some other upcoming PAM modules.

[Werkov]

The differentiation relies on split PAM configs that respective utilities ship already (sudo vs sudo-i, su vs su-l,...). common-session-noninteractive is supposed to be included in the first type. IIUC, the non-login sessions.

Do you mean moving pam_systemd to postlogin and deciding pam_systemds invocation by postlogin inclusion (or not)? (Based postlogin(5):

The postlogin configuration file is included from all individual service configuration files that provide login service with shell or file access.

)

[thkukuk]

The differentiation relies on split PAM configs that respective utilities ship already (sudo vs sudo-i, su vs su-l,...). common-session-noninteractive is supposed to be included in the first type. IIUC, the non-login sessions.

Ok, your "noninteractive" is just wrong and misleading. You are speaking about login and non-login sessions, and to not confuse everybody you should use the correct terminology. No manual page/doc speaks about interactive/non-interactive in this cases. "su" is in the same way interactive/non-interactive as "su -l" is. Same for "sudo" vs. "sudo -i".

Do you mean moving pam_systemd to postlogin and deciding pam_systemds invocation by postlogin inclusion (or not)? (Based postlogin(5):

Correct.

[Werkov]

Thanks for the explanation. I've force pushed a variant with more appropriate naming (interactive->login).

Could the split-approach be used as a precursor to possible postlogin approach?

common-session common-session-nonlogin
postlogin      ∅

How does the postlogin plan fit with ALP plan? IOW, when will it be (or not be) an acceptable change in ALP's lifecycle?

[thkukuk]

Thanks for the explanation. I've force pushed a variant with more appropriate naming (interactive->login).

Could the split-approach be used as a precursor to possible postlogin approach?

Thanks, I will try to look at this next week.

common-session common-session-nonlogin
postlogin      ∅

How does the postlogin plan fit with ALP plan? IOW, when will it be (or not be) an acceptable change in ALP's lifecycle?

The "postlogin" setup is necessary to solve some Y2038 problems. So this has to come, there is no way around. I hope we get this into the first ALP release already, if not, it has to come as maintenance update. But currently every part we fix unveils two new problems I need to look at first...

[thkukuk]

After a first look: this will become more complicated. To solve problems with different existing and upcoming modules, we need the "postlogin" implementation as done by Fedora. There is no way around that. But this does not help with pam_systemd, as "postlogin" would be far too late to call pam_systemd... So the whole stuff needs a bigger re-design.