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. > What I was implying is that the only "AFS" code is really a syscall on > most systems, and this is implemented by an internal function. On > linux, the gafstoken has a proc_afs_syscall function to open > /proc/fs/openafs/afs_ioctl or /proc/fs/nnpfs/afs_ioctl This came from > the OpenAFS code. Right, yeah. It's a very simple function in most (possibly all) cases. >> I don't think that's a good justification for making them two separate >> libraries. There's no reason why the PAM module and aklog can't link >> against the same library, and both calls have a very simple ABI. > The justification is the unknown complexity that is involved when > multiple PAM routines are used, and the libs that they drag in which may > conflict with other PAM routines. They can drag in threads, OpenSSL, > multiple versions of Kerberos. I think you're missing my point. The "make this a token" function doesn't link against any Kerberos libraries. It only has a little more complexity than the setpag function. All it does is take the blob of token that one has come up with via magical means and push it into the kernel. It is the syscall interface; nothing more or less. As such, it clearly doesn't drag in threads, OpenSSL, multiple versions of Kerberos, or anything else, and it won't cause problems for vendors and won't cause conflicts with native libraries. It's just the bit that OpenAFS has to provide to let you talk to the kernel layer. Under the hood, it may have to do complex things to attach to a Linux kernel keyring or whatever the flavor of the week is for how one shoves a token through the user-to-kernel interface, but it shouldn't be doing any complex *Kerberos* things. In fact, this routine should be entirely ignorant of the existence of Kerberos; my conception of it is that it would take the name of the cell, a blob of data, and maybe some flags like overwrite and then shove that at the kernel and let the AFS module interpret the data. Maybe I'm missing some subtlety of how this interface works that would cause this to be harder than it sounds. 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. > I would say that you would have to link in the "ticket munging logic" > with the routines to stuff the token into the kernel. Right. > But this can be separate from the setpag. It can be, but I don't see the point in maintaining two tiny shared libraries, each of which contains only one function, when you could just combine them into the "AFS system call library" that exports two equally simple (ABI-wise) functions. I have not, however, written an aklog myself (and I know you have way more experience with this than I am), so maybe I'm confused about what the interface with the kernel looks like. > 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. > Or locked out of using OpenAFS on some system with its own Kerberos > where the APIs (other then GSS) are not exposed, because OpenAFS uses > conflicting libraries. I don't want to have to replace Kerberos on a > system to get OpenAFS to work. Sure, I agree. Forking needs to be supported for right now. > I think we are pretty much in agreement. What I would like to see is > OpenAFS pick up on these. I'm happy to help do the work. I'm a little unclear right now on what direction the gatekeepers want to go with this whole area. Is there anything concrete that those of us who are fighting with these problems can do to help with that decision-making process? Provide patches that are ready to apply? Help clean out the OpenAFS bug database for completely unrelated issues so that we can free up your time to think about this? :) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
