[OpenAFS] Redux: Linux: systemctl --user vs. AFS

[Stephen]

--8323329-1997841861-1628082858=:33787
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <86eabca7-aee8-68ba-4180-f24ca4a3a4a6@email.unc.edu>

Hello, openafs folks.

I know this is a zombie thread, but at the risk of resurrecting a dead 
horse, I'm sending this message anyway.

At the time of the original thread, I did not see many of the symptoms that 
others described. I believe this was in part due to the incomplete adoption 
of systemd by the versions of Ubuntu I supported at that time, and 
partially because that many of the tools within our supported graphical 
environment (KDE) didn't yet use the "systemd --user" call.

I've been behind the curve adopting Ubuntu 20.04 (partly because I've been 
learning and implementing ansible at the same time, but mostly due to the 
pandemic). In short, I hit the behavior described by the previous thread 
hard with focal.

I lose no love for systemd, but because all mainstream linux distros now 
use it, working with and within it seems unavoidable. Uninstalling 
dbus-user-session seemed to break the DE in subtle and crunchy ways, so it 
was pretty much a non-starter for me.

The various workarounds I read about included "pam_afs_session.so nopag" in 
pam.d's common-*, uninstalling dbus-user-session, disabling "systemd 
--user", ...

Anyway, I'm writing to mention my possible solution because it might be 
useful to someone else. Also, if there's some obvious reason *not* to do 
this (beyond what I already know) someone else will see it and let me know 
what a fool I am.

My main part of my current strategy is to try to have the best of both 
worlds. First, use the "nopag" option to pam_afs_session mentioned above to 
acquiesce to the systemd per-user security model in common-auth/-session. 
This makes "systemd --user", dbus, and the rest of the console users' 
graphical environment behave normally.

The second part is to configure ssh's pam stack uniquely so that it omits 
the "nopag" flag and *does* create a pag for remote connections, so that 
remote users enjoy the added security of a pag (I'll defer to others the 
discussion of whether pags are actual security or security-theater).

Most of the machines I support fall into one of these classes:
  1. Classroom/lab desktop PC. One user at a time. SSH only allowed for 
administration.
  2. Remote-access servers. Many users at a time. Console not available to
users.
  3. Office PC. One primary user with both console and SSH access. 
Occasional ssh access by a colleague for incidental tasks.

If it matters, at my site there are no shared accounts -- each user has 
his/her own unique username and password.

This seems to work... ¯\_(ツ)_/¯ So what am I missing?

PS. Before I send, a special thanks to Jonathan Billings (and his relevant 
google doc at 
<https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub>, 
and Jeff Altman and others for arguing with Lennart Poettering on the 
behalf of pags, and us all: 
<https://github.com/systemd/systemd/issues/7261>. You can lead the systemd 
devs to school, but you can't make them think. Seriously, thanks guys.

Sincerely,
Stephen

On Sat, 17 Mar 2018, Gaja Sophie Peters wrote:

> Am 08.03.2018 um 20:08 schrieb Jonathan Billings:
>> 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,
>
> I did some testing on Ubuntu 18.04 alpha (or beta?), and ran into the
> same problem, which I solved with a variant of the above, which seems to
> work for the time being.
> The systemd-file itself goes to
> 	/etc/systemd/user/aklog.service
>
> The link to start it goes to
> 	/etc/systemd/user/default.target.wants
>
> Main advantage of course, that you don't have to make your
> AFS-Homedirectory world-readable...
>
>> 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 seems to work. "xterm" and "gnome-terminal" are still in separate
> PAGs, but since both can read the Kerberos-Ticket, both can get the
> AFS-Token. I added an "unlog" to ExecStop, so that the Token will be
> destroyed on logout. Without that, the once-obtained token will remain,
> even after logout and immidiate re-login. (Tested with manual,
> non-scripted aklog...)
>
>> 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.
>
> I tried to combine both parts into a single "aklog.service" file (see
> below). I don't know much about systemd and even less about dbus, so
> there might be things that are backwards... An added complication for me
> was that at the point where I wanted the aklog.service to be executed,
> the environment-variable KRB5CCNAME wasn't yet set, so I used a somewhat
> hackish fragment to construct the variable from the file that existed
> already in /tmp.
>
> File /etc/systemd/user/aklog.service
>>>>>>>>>>>>>>>>>>>>>>
> [Unit]
> Description=aklog for session --user
> Before=gnome-keyring-ssh.service
>
> [Service]
> Type=simple
> ExecStartPre=/bin/sh -c ' \
> 	KRB5CCNAME=FILE:$(ls -t /tmp/krb5cc_${XDG_RUNTIME_DIR#/run/user/}*|head
> -1) aklog -d'
> ExecStart=/bin/sh -c ' \
> 	dbus-monitor --profile path=/org/freedesktop/secrets/collection/login | \
> 		while read TYPE LINE; \
> 		do \
> 			[ "$TYPE" = "mc" ] && systemctl --user reload aklog; \
> 		done'
> ExecReload=/usr/bin/aklog
> ExecStop=/usr/bin/unlog
>
> [Install]
> WantedBy=default.target
>>>>>>>>>>>>>>>>>>>>>>
>
> Explanation: the dbus-monitor needs to run all the time for new logins,
> so I made it the main-process of the service. Before that, aklog needs
> to be started with a (re-)constructed KRB5CCNAME which is at that time
> missing from the environment, so I look for the newest krb5cc-file with
> the current user-ID in /tmp. The user-ID itself doesn't exist in the
> environment at that point, only the username (in $LOGNAME and $USER),
> however the userid is found as part of the $XDG_RUNTIME_DIR, so I used that.
>
> The dbus-monitor watches "something" that seems to be called exactly
> once on each login - no idea if there are better things to watch for
> (disadvantage of screensaver seemed to be that there are two lines, one
> for locking, one for unlocking). The first few returned lines start with
> "sig" or "#" and aren't interesting, the interesting lines have "mc" as
> their first word and will reload the aklog.service (KRB5CCNAME doesn't
> need to be set again).
>
> When the service ends, unlog will destroy the AFS-Token. For the
> "Before=" line, I simply looked for something that was run fairly early
> in the boot-process and told systemd, I want to run even before that.
>
> Greetings,
> Gaja Peters
>
> P.S. I have tested this ONLY in Ubuntu 18.04, it might be completely
> different in another system! D-Bus might have to be monitored for
> something else, and the variable XDG_RUNTIME_DIR might point to
> something different.
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--8323329-1997841861-1628082858=:33787--