[OpenAFS] Linux: systemctl --user vs. AFS
Dirk Heinrichs
dirk.heinrichs@altum.de
Thu, 8 Mar 2018 17:39:51 +0100
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--zPQKnHeQKMO0kUtHzdojHAm6Rjiyv0KNg
Content-Type: multipart/mixed; boundary="O6CNZIwhucmZMv8oLPpMRFIXMCAJPtygz";
protected-headers="v1"
From: Dirk Heinrichs <dirk.heinrichs@altum.de>
To: openafs-info <openafs-info@openafs.org>
Message-ID: <7f6d69d7-859d-722b-74a3-73e23621bca5@altum.de>
Subject: Linux: systemctl --user vs. AFS
--O6CNZIwhucmZMv8oLPpMRFIXMCAJPtygz
Content-Type: multipart/alternative;
boundary="------------BA50F1628C25969E69484B81"
Content-Language: de-DE
This is a multi-part message in MIME format.
--------------BA50F1628C25969E69484B81
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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...
=C2=A0=C2=A0=C2=A0 Dirk
1. Debian bug <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D84637=
7>
2. systemd bug
<https://github.com/systemd/systemd/issues/7261#issuecomment-37050940=
5>
--=20
Dirk Heinrichs <dirk.heinrichs@altum.de>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de
--------------BA50F1628C25969E69484B81
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
Hi,<br>
as some Linux users might already have noticed, there's an
incompatibility issue between systemctl --user and users having
their $HOME below /afs.<br>
<br>
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).<br>
The result is that any systemctl --user command gets a permission
denied, for example:<br>
<tt><br>
% systemctl --user enable syncthing</tt><tt><br>
</tt><tt>Failed to enable unit: Access denied</tt><br>
<br>
because the systemd --user process is denied access to the users
$HOME.<br>
<br>
There are discussions about this already in both the Debian and
systemd bug trackers (see links below).<br>
<br>
The outcome of both seems to be that the problem can be solved with
a combination of two changes:
<ol>
<li>make sure the PAM stack for systemd --user includes
pam_keyinit.so (suggested in the Debian bug discussion)</li>
<li>let AFS use the per-user keyring instead of the per-session
one (suggested in the systemd bug discussion)</li>
</ol>
Does the second one sound reasonable?<br>
<br>
Bye...<br>
<br>
=C2=A0=C2=A0=C2=A0 Dirk
<ol>
<li><a moz-do-not-send=3D"true"
href=3D"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D846=
377">Debian
bug</a></li>
<li><a moz-do-not-send=3D"true"
href=3D"https://github.com/systemd/systemd/issues/7261#issuecomment-37050=
9405">systemd
bug</a><br>
</li>
</ol>
<pre class=3D"moz-signature" cols=3D"72">--=20
Dirk Heinrichs <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:dirk.hei=
nrichs@altum.de"><dirk.heinrichs@altum.de></a>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: <a class=3D"moz-txt-link-freetext" href=3D=
"http://www.retroshare.org">http://www.retroshare.org</a>
Privacy Handbuch: <a class=3D"moz-txt-link-freetext" href=3D"https://www.=
privacy-handbuch.de">https://www.privacy-handbuch.de</a>
</pre>
</body>
</html>
--------------BA50F1628C25969E69484B81--
--O6CNZIwhucmZMv8oLPpMRFIXMCAJPtygz--
--zPQKnHeQKMO0kUtHzdojHAm6Rjiyv0KNg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEJgWJ3LIo7zNO9tmf0p7rxfc7RqsFAlqhZ1cACgkQ0p7rxfc7
RqtN8g//QS0mXvOIxLLqZ5PK/sZTwpS+zsYp0X3aM2Ri8pEb+mkivukXPzelHxQR
7W7RzfVo/ZY82SjJAZIAc0lRjA/NqFHosadBKiJclpKxfK0iyUhC2Qxm0SkfQgNe
ecwILyRsLj+wmTFer1sP90bi52+mG0WxfYXxXsEMepokCeYxidQ6A/HRT/v0L9bA
FVFZ9Ktgw8keShQVn5t5MulwLIl+jJyb/WHK+FqxgFodn1IjmOOIT/BF2WBXcr27
78G+A4/ZBKW8h0ZFVNvgDGGOvGa/5MVDrn8adj0D9gDdEvJWGjuX0l9o4bs0VBIm
U4RMWe1N6MwDuU2idbXAHHVz278ukK47a26QlSHu6xMfkFLGlVNgoXfMC2d1mO0p
tkQx0dyUEX7t3m8rA9noLv+/D5HRUxmexNr0wiMtoh0B0nnNGnILwNmrloXkLBs+
AznWHB+7jUV+JXthQxsd164JEc+uSrzqpmSpwphq7H/PBMuNfBszwK1oE3MKeI1Q
UivDDumKkHL/rqkh1FkK4QLowDVkJoGzsVNKwsWcnYNFJj89lrNDhFjL6h0CurMe
bOapRuktMwwZtMfjIhx90KsTty54EDwGhbIrsz4p9pi8MV5DLFS7M1kgADHKlwnt
qtwrh9V+SL/Wj+lVX1liO+AoqlvRiZIFHLEhE//YhBpjWJSp3Fc=
=uh3y
-----END PGP SIGNATURE-----
--zPQKnHeQKMO0kUtHzdojHAm6Rjiyv0KNg--