[OpenAFS] Linux: systemctl --user vs. AFS
Jonathan Billings
jsbillin@umich.edu
Thu, 8 Mar 2018 14:08:17 -0500
--001a11375848fda2b20566eb651b
Content-Type: text/plain; charset="UTF-8"
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.heinrichs@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.heinrichs@altum.de> <dirk.heinrichs@altum.de>
> GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
> Sichere Internetkommunikation: http://www.retroshare.org
> Privacy Handbuch: https://www.privacy-handbuch.de
>
>
--
Jonathan Billings <jsbillin@umich.edu>
College of Engineering - CAEN - Unix and Linux Support
--001a11375848fda2b20566eb651b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>There's a google doc in the Debian bug that =
I wrote (<a href=3D"https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKt=
I-Qh00c5_9zJa4YHjnpB6ODM/pub">https://docs.google.com/document/d/1P27fP1uj-=
C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub</a>), which was to create an /etc/sy=
stemd/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.=C2=A0 This assumes that it's got its own keyring.<br>=
<br></div>This works, to a certain extent.=C2=A0 I also have a startup scri=
pt that I wrote that runs dbus-monitor to watch org.gnome.ScreenSaver, and =
restart the aklog.service user service every time you unlock the screensave=
r, so those tokens get renewed with the updated krb5 credentials.<br><br></=
div>It's all very hacky and is a constant source of pain for me since I=
use AFS as my $HOME.=C2=A0=C2=A0 I feel like a better solution would be to=
not start systemd --user externally to your login session (and PAG) and in=
stead have it start up as part of the PAM stack, but that isn't systemd=
-ey enough.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Mar 8, 2018 at 11:39 AM, Dirk Heinrichs <span dir=3D"ltr"><<=
a href=3D"mailto:dirk.heinrichs@altum.de" target=3D"_blank">dirk.heinrichs@=
altum.de</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div 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 href=3D"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D84=
6377" target=3D"_blank">Debian
bug</a></li>
<li><a href=3D"https://github.com/systemd/systemd/issues/7261#issueco=
mment-370509405" target=3D"_blank">systemd
bug</a><span class=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></li><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></ol><span class=3D"HOEnZb"><font color=3D"#888888">
<pre class=3D"m_5874998201020751834moz-signature" cols=3D"72">--=20
Dirk Heinrichs <a class=3D"m_5874998201020751834moz-txt-link-rfc2396E" href=
=3D"mailto:dirk.heinrichs@altum.de" target=3D"_blank"><dirk.heinrichs@al=
tum.de></a>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E5<wbr>4246986015
Sichere Internetkommunikation: <a class=3D"m_5874998201020751834moz-txt-lin=
k-freetext" href=3D"http://www.retroshare.org" target=3D"_blank">http://www=
.retroshare.org</a>
Privacy Handbuch: <a class=3D"m_5874998201020751834moz-txt-link-freetext" h=
ref=3D"https://www.privacy-handbuch.de" target=3D"_blank">https://www.priva=
cy-handbuch.<wbr>de</a>
</pre>
</font></span></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature">Jonathan Billings <<a href=3D=
"mailto:jsbillin@umich.edu" target=3D"_blank">jsbillin@umich.edu</a>><br=
>College of Engineering - CAEN - Unix and Linux Support<br><br></div>
</div>
--001a11375848fda2b20566eb651b--