Juha Jäykkä <[EMAIL PROTECTED]> writes: > Seems to me, then, that PAM is lacking proper handling of user > authorization. It may not be much different from handling authorization > and authentication together, but looks like having different hooks for > these different things might be a good idea. Go whine to PAM people? =)
PAM is lacking a lot of things, the worst of which being a clear and complete specification that everyone follows. The problem is not so much knowing what it needs as figuring out how to get there from here. Unfortunately, everyone has implemented PAM, everyone has hacked around each other's bugs, and there are dozens of different ways of doing PAM that all sort of work and that are all used in practice. I'm not sure how you'd practically manage to fix the problem without introducing a new protocol and a new API that's clearer and more strictly enforced up-front and making everyone migrate, something that would most likely take a decade. I'm not particularly optimistic about making significant changes to PAM at this point. For the time being, we probably have to live largely with what we've got. > As what comes to various other things discussed under the topic, the > first solution I came up with was to add the sshd host to PTS, and give > rl to this principal, but sshd *leaks* this token to the user. Is this > actually a PAG problem? sshd won't leak this token to the user if your PAM setup is appropriate. You have to make sure that the user is put into their own PAG as part of the session initialization process, even if they don't get a token. > [Russ: the earlier problem on debian-devel was indeed related to the > aes keys, so thanks for that, too.] Ah! Thank you for saying! I never would have guessed that, and now I'll know for the future. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
