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 <[email protected]>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to