[OpenAFS-devel] Simplified integration of OpenAFS, Kerberos SSH and PAM (again)

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> 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.

> 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.

> 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.  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.

> 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.  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.  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.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>