> That approach sounds interesting. Are the specifics documented anywhere for > someone wanting to replicate and evaluate it?
It is as basic as it sounds. Setting up sssd is documented in its manpages and gets as complicated and messy as your site requires. user@.service: We literally changed the ExecStart= directive to a shell script that reads like: if [ ! $guard-against-system-accounts ]; then export KRB5CCNAME=/path/to/cache-depending-on-$(id -u) aklog fi exec /path/to/systemd --user > 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! Yes that is true! I rarely have to do AFS administration. So, I have a shell script that drops me in a pagsh and acquires a token based on an in-memory kerberos ticket (you have to use heimdal's kinit with -afslog option for that). Leaving the sub shell destroys the token. The in memory ticket turned out to be even more important for not leaking the privilege into the now well-known ticket cache than leaking the token to other processes. Using systemd removes most of the PAG contagion headaches, as one rarely starts any service directly but via systemctl, which merely communicates to systemd, which starts the services under its own process context. –Michael _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
