Usually i geht rid of a pag with
keyctl new_session
Might possibly work for you.
To (re)start Prozesses, i am using "at",
e.g.
echo /usr/sbin/sshd | at now

Regards, Rainer


------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>



--- Original-Nachricht ---
Von: Stephen
Betreff: Re: [OpenAFS] Redux: Linux: systemctl --user vs. AFS
Datum: 05. August 2021, 18:32
An: [email protected]
Cc: [email protected]




Michael,

Thanks for the reply.

On Thu, 5 Aug 2021, [email protected]
<mailto:[email protected]> wrote:

> While this thread is live again, let me contribute my own findings on
> this. Our network runs mainly NixOS machines.
>
> For us, using sssd for Kerberos ticket management turned out to be a huge
> benefit, mainly for its centralized ticket refresh functionality. We hold
> users' tickets in well-known files. Using sssd lifts the necessity to
> have the directory holding ticket caches user-writable. So, well-known
> cache files is not a security concern anymore.
>
> We use systemd, as well. We have set up the [email protected]
<mailto:[email protected]> in a
> way, that it acquires an AFS token before starting. Thus, all dependent
> user services have AFS access. This is what we need well-known ticket
> cache files for. PAM has already run at the time, so the cache is hot.

That approach sounds interesting. Are the specifics documented anywhere for
someone wanting to replicate and evaluate it?

> Lingering does obviously not work with this setup.
>
> We use nopag tokens, as we don't believe in its added security promises.
> In parallel, we allow ticket forwarding for remote logins, mainly for the
> benefit of single sign-on. So, this circumvents most promises, PAGs would
> give us anyway.
>
> nopag also allows us to post-acquire AFS token for systemd services of a
> running session, which is important for road-warrior (does one still use
> this term?) setups.
>
> PAGs are a big usability bonus, though, when using pagsh to temporarily
> acquire an administrative shell.

I have also enjoyed this functionality historically. My worry though is if
you use nopag everywhere, but then use pags for admin tasks, what happens
if you accidentally start a shared process (sshd, etc) from an admin PAG
when you and/or the process are assuming tokens are per-uid, rather than
per-pag?

To the best of my knowledge, there's no way for a process to drop a PAG
once it is started within one and once you're in a PAG, tokens are then
per-pag and not per-uid. That's why I took the hybrid approach where ssh's
pam still creates PAGs on login (basically all of my admin occurs via ssh
either manually or via ansible).

Someone please correct me if my assumptions or understanding are wrong!

> Hope this helps!
>
> –Michael
> _______________________________________________
> OpenAFS-info mailing list
> [email protected] <mailto:[email protected]>
><https://lists.openafs.org/mailman/listinfo/openafs-info>

Reply via email to