Christian Hesse <[email protected]> on Fri, 2017/09/29 16:30: > Christian Hesse <[email protected]> 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);}
pgp5ydRP5nwEh.pgp
Description: OpenPGP digital signature
