On 5/11/05, Russ Allbery <[EMAIL PROTECTED]> wrote: > Douglas E Engert <[EMAIL PROTECTED]> writes: > > > aklog -setpag is another problem, as a child being able to change the > > parent process is sort of against unix basic principals. I don't think > > this works on all systems either. > > Right, I agree. I think that newer kernel models are going to make this > difficult to maintain. This is just what libpam-openafs-session is doing > right now because it's what worked without requiring libraries not > suitable for linking to a PAM module. >
Yeah. I think setpag() should be made to have similar semantics to setsid(). > > The idea is that your aklog implementation would then use this routine to > push the token into the kernel, after it's done whatever it has to do in > Kerberos terms to get the thing ready. And the library that provided this > routine and the setpag routine would basically be the "AFS system call > library" with no dependencies on any other libraries at all. It's job > would just be to expose the system calls that userspace programs that > aren't AFS programs need to use as functions with a highly stable ABI. > One quick point, do we need to worry about issues related to the future move away from the 1:1 cell to key mapping? As long as the library API treats the creds as opaque, I guess this isn't an issue. > > Another way to do this is to ask the AFS Kernel modules to have a helper > > process to get tokens using the ticket cache. If AFS every wants to have > > different principals for different AFS servers, it will need something > > like this. > > Personally, I think it's more likely that the trend will go the other > direction and people are going to start wanting to put Kerberos ticket > caches in the kernel the way tokens are now. I could be wrong, but the > kernel call back down into user space to try to find the user's ticket > cache seems fraught with danger to me. The kernel is actually better > positioned to keep ticket caches attached to the right processes and make > sure that only authorized processes can get at them. > I'm a fan of making AFS act more like a traditional K5 service, so I like Doug's idea of automated cred acquisition using the ticket cache. Frankly, I hope the next-generation security architecture eliminates any need for credential translators like aklog. In a multi-key cell it's not going to be efficient for something like aklog to do TGS reqs for the service principal of every fileserver (or fileserver group). Since many PAGs will end up making conns to only a small subset of the fileservers in a cell, I think TGS reqs should happen on an as-needed basis. The downside is this means you either need something similar to the DCE kernel authn helper daemon and upcall interface, or a fairly robust in-kernel library to handle GSS, K5 and ASN.1. It would be nice if the various NFSv4/rpcsec_gss client projects resulted in OSs developing generic kernel APIs to address things like service ticket acquisition, and credential cache management... If you're right, and vendors start putting the krb5cc in the kernel, then we might be able to leave credential stuffing up to projects like pam_krb5. Then, we could focus our attention on mapping a PAG to a particular kernel credential cache. -- Tom Keiser [EMAIL PROTECTED] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
