On 9 Mar 2018, at 11:06, Dirk Heinrichs wrote: > Am 08.03.2018 um 18:54 schrieb Jeffrey Altman: >> Switching to the user keyring is unreasonable. The impact of such >> a change is that all user sessions on a system share the same tokens >> and an effective uid change permits access to those same tokens. >> >> Process Authentication Groups (PAGs) exist explicitly to establish a >> security barrier to prevent such credential leakage. > > I understand. However, why not let the user (or better: admin) decide? > I assume this is coded in the cache manager, so the module could be > enhanced with a parameter that allows to choose between the two variants > at module load time.
Chances are very good that most administrators won't really understand the security issues. Or maybe THEY will understand, but their users will not. And then the users will get into weird problems with no understanding of what is causing the problem. So let's say someone has multiple services running under their userid's keyring. One of them does a klog to a different AFS identity (because it needs to), or it does an unlog. My guess is that that change will immediately happen to all the other services, and that the other services might fail in very weird ways. Or say one of those services has to do a 'sudo' (such as to copy files from AFS space into local filesystems), and immediately loses access to the very file(s) that it needs to copy. Note: when I was first trying to figure out PAM on linux I did not have things setup right, and therefore I would get uid-based auth instead of PAG-based auth. It "mostly works okay", but I kept hitting irritating edge cases where things go wrong and it takes a few minutes to realize why. And usually this happens in the middle of trying to fix something *else* which has gone wrong, and you *really* don't want any additional headaches! -- Garance Alistair Drosehn = dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
