There's a google doc in the Debian bug that I wrote ( https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub), which was to create an /etc/systemd/user/aklog.service that is automatically started as part of the login, what it does is runs an aklog so that the processes started by systemd --user have tokens. This assumes that it's got its own keyring.
This works, to a certain extent. I also have a startup script that I wrote that runs dbus-monitor to watch org.gnome.ScreenSaver, and restart the aklog.service user service every time you unlock the screensaver, so those tokens get renewed with the updated krb5 credentials. It's all very hacky and is a constant source of pain for me since I use AFS as my $HOME. I feel like a better solution would be to not start systemd --user externally to your login session (and PAG) and instead have it start up as part of the PAM stack, but that isn't systemd-ey enough. On Thu, Mar 8, 2018 at 11:39 AM, Dirk Heinrichs <dirk.heinri...@altum.de> wrote: > Hi, > as some Linux users might already have noticed, there's an incompatibility > issue between systemctl --user and users having their $HOME below /afs. > > Background: systemctl --user is the per-user equivalent of systemctl, > which means starting services on behalf of the current user. For this to > work, a corresponding systemd --user process is started upon the users > first login. However, the problem here is that this process is not started > from the users session, but from PID 1, and runs through its own PAM stack > (which is non-interactive and therefor doesn't get an AFS token). > The result is that any systemctl --user command gets a permission denied, > for example: > > % systemctl --user enable syncthing > Failed to enable unit: Access denied > > because the systemd --user process is denied access to the users $HOME. > > There are discussions about this already in both the Debian and systemd > bug trackers (see links below). > > The outcome of both seems to be that the problem can be solved with a > combination of two changes: > > 1. make sure the PAM stack for systemd --user includes pam_keyinit.so > (suggested in the Debian bug discussion) > 2. let AFS use the per-user keyring instead of the per-session one > (suggested in the systemd bug discussion) > > Does the second one sound reasonable? > > Bye... > > Dirk > > 1. Debian bug > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846377> > 2. systemd bug > <https://github.com/systemd/systemd/issues/7261#issuecomment-370509405> > > -- > Dirk Heinrichs <dirk.heinri...@altum.de> <dirk.heinri...@altum.de> > GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 > Sichere Internetkommunikation: http://www.retroshare.org > Privacy Handbuch: https://www.privacy-handbuch.de > > -- Jonathan Billings <jsbil...@umich.edu> College of Engineering - CAEN - Unix and Linux Support
