Russ Allbery wrote:
Douglas E Engert <[EMAIL PROTECTED]> writes:
Russ Allbery wrote:
This is already what Debian does,
Thats part of the argument, its a single vendor's solution. What about the other vendors, including SUN, HP, IBM, SGI, MAC and other Linux.
The only piece of code that's in Debian related to this that hasn't been assembled from freely available software is a small PAM module that calls aklog -setpag, so I honestly think we're in about the same place here. Like I said, it's really all already out there except for the PAG piece.
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.
That is the intent of gafstokens. It uses syscall or on linux the /proc file to set the PAG. It uses no AFS headers (but could) or libs, is PIC code, and protects itself by trapping some signals. It fork/execs an aklog like program to get the tokens. It compiles to libgafstoken.so
I think this would be great. This sounds like exactly the right solution to the PAG problem to me. Previously, one had to use KTH Kerberos or Derrick's variation on the same idea to get the same effect, KTH Kerberos has various portability problems to recent Linux versions and builds quite a bit more than just that library, and none of that is conveniently there when one builds AFS.
I agree, For the PAG it could even be a macro, as it really comes down to a syscall.
It's probably better as a function, though, just in case. One never can tell what additional complexity may be needed long-term.
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.
I would rather see two seperate libs, as the PAG needs to be obtained from the session leader, which usually means it has to be called from some system deamon, like sshd, or dtlogin,or gdm usually from PAM.
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 want to be able to use OpenAFS on systems who provide their own Kerberos libs. If/when OpenAFS adds full Kerberos support for using K5 tickets as tokens, will there be conflicts? I have run into these types of problems with working with DCE.
Hopefully the only part of AFS that needs to be dragged into login is setpag.
I *don't* advocate putting any of the ticket munging logic into the library, just the minimal "here's a binary blob that I already formatted appropriately; please stuff it into the kernel and call it a token" interface. It makes packaging and other things much easier if we don't increase the number of libraries unnecessarily.
I would say that you would have to link in the "ticket munging logic" with the routines to stuff the token into the kernel. But this can be separate from the setpag.
The tokens on the other hand can be obtained from a child process like aklog.
Forking external programs out of a PAM module is an ugly way of getting
tokens.
I know its ugly, but it works and avoids a lot of problems.
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.
It's probably the best currently available way of doing it while
there are three hundred different aklog implementations that all do
slightly different things, but hopefully that won't be the case in the
long run as matters converge on K5.
Again, I want to be able to use OpenAFS on systems which provide their own versions of Kerberos. The problem is you need to authenticate, get a PAG and AFS token all in the same process usually via PAM. The vendor's version of Kerberos may not be the version used within OpenAFS, so even though they may all be in the same process, they may not be able to share libs, or krb5_context. At least the multiple implementations of Kerberos agree on a common ticket cache format and you can't count on much more.
While I think supporting the fork and
exec hack is the right thing to do for the time being, I don't want to get
locked into any system that prevents us from doing the right thing down
the road.
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.
I think we are pretty much in agreement. What I would like to see is OpenAFS pick up on these.
--
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
