As gdm/sddm include it's own pam_keynit module before sourcing system-login it'll be effectively called twice. Is this a problem? > -------- Original Message -------- > Subject: Re: [arch-dev-public] systemd, kernel keyring and pam_keyinit > Local Time: October 6, 2017 1:04 PM > UTC Time: October 6, 2017 1:04 PM > From: list@xxxxxxxx > To: arch-dev-public@xxxxxxxxxxxxx > > Christian Hesse <list@xxxxxxxx> on Fri, 2017/09/29 16:30: >> Christian Hesse <list@xxxxxxxx> on Mon, 2017/09/18 14:29: >> > Hello everybody, >> > >> > systemd v233 introduced code that makes use of the kernel keyring, >> > initializing a private keyring for every service and adding a protected >> > key named "invocation_id". This caused some trouble and we reverted it >> > since then. >> > >> > Things will change with systemd v235, which adds a new option >> > "KeyringMode=" for units. The values are "inherit", "private" and >> > "shared". The commit [0] message and changes give the details. Now >> > cryptsetup units are generated with "KeyringMode=shared", which unbreaks >> > this use case. Other services that use the kernel keyring and want to >> > share secrets with other services have to add this as well. >> > >> > However login sessions where user context is changed can not be handled by >> > systemd. Looks like we have to update our PAM configurations and add a >> > line for every service where session is expected to use the kernel >> > keyring: >> > >> > session optional pam_keyinit.so force revoke >> > >> > This is required for eCryptfs to function properly. >> > Any comments on this? Any concerns? >> > >> > I would like to keep the upstream keyring behavior with release version >> > 235. Would be nice to have this sorted before. >> > >> > [0] >> > https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3feebe669 >> >> So we have a flyspray ticket requesting the same [1] and a report from >> Mantas who is already using a setup with pam_keyinit. >> >> As systemd upstream started preparing a release and milestone items are >> being resolved [2] I would like to see some progress. Who will do this? >> Dave, do you update pambase? Do we add a todo-list containing all packages >> with pam configuration files so maintainers can decide on their own whether >> or not this is feasible for the package? >> >> [1] https://bugs.archlinux.org/task/54915 >> [2] https://github.com/systemd/systemd/milestone/12 > > Pushed systemd 235.0-1 and pambase 20171006-1 to [testing]... > Let"s wait for people to complain. :-p > -- > main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" > "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) > putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
