Drop fedora-specific PAM config, document instead what PAM modules systemd --user requires

[fsateler]

Submission type

• Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

231

Used distribution

Debian

In case of bug report: Expected behaviour you didn't see

Upstream ships generic configuration, and where it can't, it documents the things it needs/wants

In case of bug report: Unexpected behaviour you saw

The upstream provided pam config uses fedora-specific files.

Debian patched the config file to be useful on debian, but really this should just be documented and downstream distros should provide the relevant configuration/scripts.

[fsateler]

xorg/50-systemd-user.sh seems to also be Fedora-specific, so it should be dropped as well. In debian an equivalent is shipped by the dbus package.

[poettering]

Hmm, well, any chance we can come up with a basic PAM file that works on both distros? (i.e. something that is good enough to boot on both systems, but that the downstream distros might still have to patch)?

Debian has a similar directory as the Fedora one we place 50-systemd-user.sh in, no? I am pretty sure this code should be unified between the two distros, and doesn't belong in the dbus package really...

I'd rather ship a file here that is "good enough" for both distros, but that enables people who build independent distros to have a good starting point, rather than leave things out completely.

[mbiebl]

@poettering I guess it will be hard to unify the pam configs. For that distros are just too different in that regard from my experience.

As for 50-systemd-user.sh: it's installed in /etc/X11/xinit/xinitrc.d/. This directory seems to be Fedora/Redhat specific. Under Debian/Ubuntu and derivates, there is no such directory.
We have /etc/X11/Xsession.d/, which serves a similar function as /etc/X11/xinit/xinitrc.d/ but is used a bit differently.

[poettering]

@mbiebl well, I am pretty sure that the set of PAM modules called is not totally different, and that the major difference is maybe in the scope and the use of include files, no?

use the script a bit differently? in which way?

If they are similar enough, we should really add --with-x11-session-dir= or so for "configure", so that distros can choose what they need.

[mbiebl]

@poettering
The scripts in /etc/X11/xinit/xinitrc.d/ seem to be stand alone scripts which I suspect are executed one after the other.
The scripts in /etc/X11/Xsession.d/ are sourced and not executed.

[martinpitt]

We could ship a PAM config without any includes, i. e. expand out Debian's common-account and common-session-noninteractive, and Fedora's {account,session} include system-auth:

# common account modules
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so

session required pam_selinux.so close
session required pam_selinux.so nottys open
session required pam_loginuid.so

# common session modules
session optional pam_keyinit.so revoke
session required pam_limits.so
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

session optional pam_umask.so
session required pam_unix.so
-session optional pam_systemd.so

(Haven't actually tested this)

However, this would then be ugly/too static everywhere, as both Debian's common-session and Fedora's system-auth are autogenerated by pam-auth-update/authconfig and need to be adjusted to packages that you install/remove (e. g. pam_ecryptfs). So maybe the common account and session modules could be specified as ./configure arguments to avoid expanding them in the source.

[poettering]

The scripts in /etc/X11/xinit/xinitrc.d/ seem to be stand alone scripts which I suspect are executed one after the other.

Nope, on Fedora they are sourced by /etc/X11/xinit/xinitrc-common. The concepts are really pretty much the same. The distros just deviate on the paths...

[poettering]

@martinpitt well, i want to ship a basic PAm config at least that is sufficient to make things work if you build your own distro from scratch. Ideally this should be a config that works well enough on both of Debian and Fedora-derived distros. But that doesn't mean that distros packaging systemd would leave it as is.

So, I see two possibilities here:

a) Ship a generic version with "expanded" includes, that does the same thing on Fedora/Debian and everything else, and that downstreams then minimally modify kicking out the lines they have in their includes, and adding an include stanza instead.

b) Maybe it is sufficient to just make the name of the include file configurable during build time, via a new configure option. If so, we'd use some generic name, and downstreams would just specify what they need there, but the default would work everywhere...

(Not sure if b) is possible, but if it isn't a) is an OK choice in my eyes, too).

Does that make sense?

[mbiebl]

I'm including here the pam configs from Debian

@include common-account

session  required pam_selinux.so close
session  required pam_selinux.so nottys open
session  required pam_loginuid.so
session  required pam_limits.so
@include common-session-noninteractive
session optional pam_systemd.so

and Fedora

account  include system-auth

session  required pam_selinux.so close
session  required pam_selinux.so nottys open
session  required pam_loginuid.so
session  include system-auth

We explicitly had to include the pam_limits.so module here, because that is not included in common-session-noninteractive in Debian. See the related Debian bug report [1] which actually was the reason why Felipe filed this upstream bug report in the first place. Even if we make the includes configurable, we don't know if the included snippets actually provide everything needed. So a generic, expanded pam config seems like the more useful approach to me.
That the include mechanism is used differently between distros doesn't really help either.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838191

[johannbg]

Is there any hard dependency between pam and systemd? I

if not it makes no sense for shipping files associated with pam and that the integration of that entirely left to those downstream that use it.

I would not be surprise if there existed Debian based variants that do not ship pam and are or would like to ship systemd so they end up having to patch those generics out anyway so you can just as well drop it unless there is hard requirement on it.

+It's much more likely that an mutual agreeable result for good generic upstream defaults can be achieved and used by downstream if and then when pam2 or the pam replacement emerges.

[poettering]

Is there any hard dependency between pam and systemd? I

Well, semi-hard. PAMName= requires PAM, and user@.service makes use of it.

I am pretty sure that if a compile-time option is enabled we should install everything needed to make the thing work, without requiring distros to add more stuff in.

[poettering]

So my suggestin would be to include a PAM snippet like this in systemd:

session required pam_selinux.so close
session required pam_selinux.so nottys open
session required pam_loginuid.so
session optional pam_systemd.so

This appears to be the common core both distros use, and actually encodes valuable information (as the audit creds pam_loginuid sets up are actually used by pam_systemd, and hence needs to be ordered as above).

The downstream distros would then just add in their specific include lines. (or, if they want to replace it entirely, that's OK too, but at least this way they can use this as an example to start from).

Does this make sense?

[martinpitt]

We can ship a minimal one as well of course; however, the main effect will just be that every package has to patch it differently. We certainly don't need things like ecryptfs or keyinit in there, but I'm fairly sure that we should at least add limits and umask. The one I put into #4284 (comment) is a merge of Debian's and Fedora's expanded file which in pretty much all cases will do too much. Question is if it's better to do too little.

FWIW, I consider the PAM part an issue which can be bikeshedded about for hours and which probably will never have a perfect upstream solution anyway, so TBH I wouldn't waste too much effort on it.