Russ Allbery 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.
(The pam_afs2 could also be used from the pam_sm_setcred after the pam_krb5 and is usefull on Solaris with dtsesion for screen unlock.)
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.
AIX was messy, but I have not looked at AIX in a few years.
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.
OK, the same lib could have the setpag routine and ktc_setToken like routine as Jeff points out as long as it does not require any extra libs.
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.
OK, as long as it is simple, and does not drag in extra stuff.
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.
Yes this might happen, NFSv4, gss-rpc etc. But this is hard to do, and may tak a while, and different vendors might do it differently as well.
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? :)
I could not have said it better. Count me in on this too.
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
