On Wednesday, April 13, 2005 10:43:50 PM -0700 Russ Allbery <[EMAIL PROTECTED]> wrote:
Moved to openafs-devel.
Derrick J Brashear <[EMAIL PROTECTED]> writes:On Wed, 13 Apr 2005, Douglas E. Engert wrote:
pam_afs2 in not doing authentication, it is there to get a PAG and token using the credentials saved by a previous pam or by the application like OpenSSH.
I wrote that in like 1997, it was called pam_afs, used the kerberos tickets gotten by pam_krb4, and linked libraries instead of forking;-)
The difficulty with doing this right now is that PAM modules need to be PIC and right now none of the AFS libraries are built PIC, so it's hard to get at setpag. Also, PAM modules in practice need to be thread-safe, so they need to be built against the new pthread-aware AFS library API rather than the old one (although this mainly affects the PAM modules bundled with OpenAFS).
I was thinking about grabbing a copy of the latest 1.3.x source and working on this, unless there's something else I should start from. Is someone else already working on it?
There are lots of ways to do this, but the best way would be to import libtool and build the new AFS libraries with it (not worrying about the old ones for the first pass). This means that anything built against those libraries would also need to be built and installed by libtool. What are the opinions around these parts on libtool?
I don't particularly care for libtool. It imposes a lot of structure trying to solve problems that most people don't actually have, and imposes unnecessary restrictions that make my life annoying. It plays poorly with objdir builds and DESTDIR installs. It's probably the best general-purpose solution in this problem space, but that doesn't mean it doesn't suck.
In addition, the problem libtool solves is one we don't actually have. The libraries you're talking about (libafsrpc and libafsauthent) are _already_ available in shared, pthreads-aware versions.
Finally, I'm not sure I agree with your assertion that these are the "new" API's that everything should use. While they begin to move in the right direction with respect to library makeup, it's not quite right, and if we're going to spend effort in this area, we should try to do something that doesn't suck, and that's consistent along both the static-vs-shared and lwp-vs-pthread axes.
Oh, and to the person who said they wanted to see one big 'libafs.so' library -- we should not produce anything named 'libafs' that is not our kernel module. I guarantee that doing so will cause confusion.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
