Jeffrey Hutzelman <[EMAIL PROTECTED]> writes: > Sure. But "remembers a key for me" is not a better native mechanism. > It is a solution to a completely different problem. > As long as you get the refcount (or eq), what's the problem with using the keyring mechanism to store a PAG id for you?
> Actually, I suspect we'd be willing to allow less strict semantics for > (b) than you describe. But I'll have to think about that for a bit > Interested in that one. My main problem with the last lkml patch I saw is that session keyrings are cleared for "SUID programs and setuid()/setreuid()/setresuid()". I can see that this functionality is handy for some daemons, so those semantics won't change. If we want something else, we'd better have some good and obviously valid arguments. I'd say that my id(s) for the distributed system(s) don't necessarily have anything to do with my local uid, so changing uid shouldn't affect my creds for the distributed system(s). Just like doing kinit shouldn't affect my local uid. I can say that being forced to reauthenticate (or similar) to be able to run my scripts in AFS every time I run sudo would be annoying. Comments? Better examples? /Tomas _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
