[OpenAFS] pam-afs-session 0.1 released

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> writes:
> Russ Allbery wrote:

>> This isn't good default behavior since, for instance, it will fail to
>> get tokens when the user's home directory isn't in AFS.  I added an
>> option to request this behavior, though.

> Yes, this is a problem with all the aklog programs, You cant specify get
> a token for the default cell of the machine and for the cell that
> contains the user's home directory. A partial fix is if the home
> directory is not in /afs then don't use the -p option.

Yeah, that's a thought, but symlinks and the like still make that hard.
I'm going to go with the option for the short term, and in the long term
we can revisit it.

>> (At some point, I'm going to have to figure out what to do if the
>> program to run isn't a simple program name but has some options
>> attached.  Oh well, I can put that off for right now.)

> Actually it can be a script. Very handy for debugging.

True.  But that requires that the user set up the script, and for users
who just need to, say, pass -524 to aklog, it would be convenient if the
package could just handle such a setting.  It makes it hard to parse the
PAM arguments, though.

I'm planning on adding an option (build-time) to link against the Kerberos
libraries and then use the appdefault functions to also pull settings out
of krb5.conf, the way that my pam-krb5 module does.

>> Well, those are two different questions.

>> If AFS isn't available, the module should log a message and return
>> success.  That's what it does now.

> I say a lot of PAM_SESSION_ERR. For example, if the aklog program can
> not be found, or the return status is not zero.

Right, I'm dealing with them individually.  I believe the module should
print a message and succeed if:

 * AFS is not present (k_hasafs fails).
 * The module has already ran.
 * We're in close_session or deleting creds and the module didn't get a
   token successfully during open_session or setcred.
 * There is no Kerberos ticket cache and we weren't configured to run
   aklog anyway.
 * We were configured to ignore this user.
 * PAG creation succeeded but aklog failed.

The module should error out if:

 * We couldn't allocate memory.
 * AFS was present but PAG creation failed.
 * We couldn't fork.
 * pam_get_user fails.
 * getpwnam on the user fails (applications should not open sessions or
   call pam_setcred for non-local users).
 * k_unlog failed after k_hasafs succeeded.

This one is still debatable but currently is a failure; let me know if
that seems wrong.

 * aklog succeeded but we were unable to set PAM data afterwards.

This includes the fixes made based on your last message.

> OK, I will buy a failed PAG, but not a failed token. But why would the
> PAG fail? The main reason would faiulure of the kernel extensions to
> load, afsd did not start (yet).

It shouldn't ever fail, since we already verified that AFS was running
with k_hasafs.  But if it does fail for some reason (out of kernel memory,
perhaps), I want to fail the PAM stack since we didn't isolate the user in
their own PAG.

>> I was going to punt on anything other than Linux for the built-in AFS
>> syscall support, but after thinking about, I think I can get the system
>> call number from the OpenAFS headers and add the other syscall testing
>> code for the systems where this is easy.  That won't cover AIX, but AIX
>> doesn't use PAM anyway so far as I know.

This has now been implemented, although I haven't tested it yet on
Solaris.  I may release 0.2 untested except on Linux and then do a quick
0.3 based on the results of testing on Solaris.

> Another way to do this, is to make this routine part of OpenAFS, as it
> has no Kerberos code and only depends on OpenAFS.  In effect your
> sys-linux.c code is the OpenAFS src/sys/setpag.c and src/sys/glue.c They
> already have headers and the syscall number.

Right, this is where libkopenafs comes in.  The code in the PAM module is
only a stopgap until the OpenAFS tree exports that functionality in a
reasonable shared library the way that Heimdal does.

I could integrate the PAM module into the tree and separately compile that
code.  The reasons why I chose not to do that are:

 * I think it's to the general benefit of OpenAFS to have that libkopenafs
   interface anyway rather than rebuilding those files internally.  Other
   external programs besides the PAM module want to be able to make AFS
   system calls.  I want a clean ABI here rather than building everything
   as part of AFS.

 * Forking and execing a program in a PAM module can be made to work and
   in some cases is the right solution, but I find it really ugly and
   would prefer to do without it.  The long-term goal for this PAM module
   is to support the libkafs token interface as well so that everything
   can be done within one process.  This means supporting building with
   different Kerberos libraries depending on which Kerberos implementation
   one uses, and that in my opinion works better outside of the tree.
   aklog is already a bit annoying because of the external Kerberos
   dependency (which keeps us, for instance, from easily distributing
   aklog with binary packages), and Heimdal even provides its own.

 * I want to be able to support Arla users with the same PAM module, as
   well as both MIT Kerberos and Heimdal users, and users who are using an
   aklog that is unrelated to either.  The code they all need is basically
   identical, and I won't want to make them download all of OpenAFS just
   to build the PAM module.  This argues for a separate distribution.

 * Just from a project management standpoint, I want to have a separate
   release cycle from OpenAFS.  I have been releasing new versions of my
   Kerberos PAM module about once a month, and for this module I'll be
   releasing new versions even more quickly while it's in active
   development.  I want to be able to release it based on its own
   stability and feature additions and not have to wait for all of OpenAFS
   to stabilize around a new release.

> (The pam_afs2 calls the gafstoken routine that used to work on AIX, and
> not fail if AFS was not load. But we don't have any AIX systems any
> more. We had the MIT r* commands calling gafstoken at the right time.)

Yeah, there's also code in the Heimdal libkafs to handle this case, but to
do it properly, you have to use dlopen, and that's more work than I want
to do in the PAM module.  I'm even hoping to avoid it with libkopenafs,
but we'll see.

>>> +*-solaris*)
>>> +	if test "x${CC}" = xgcc ; then
>>> +		LDFLAGS="-Wl,-z,muldefs $LDFLAGS"
>>> +	else
>>> +		LDFLAGS="-z muldefs $LDFLAGS"
>>> +	fi
>>> +	;;
>>> esac

>> This looks wrong.  Why do you have to allow for multiply-defined
>> symbols on Solaris?

> Depends on the compiler and how it passes options to the loader.  You
> also have the option of using either the GNU loader or the Solaris
> loader. Most site use the Solaris loader even with gcc.  Gets real mesy,
> but not as bad as on HP.

That's an explanation for why there are two cases, which I get.  What I
don't understand was why you had to set that flag at all.  muldefs means
to allow multiple definitions of symbols, and this PAM module shouldn't be
doing that.

This isn't the same as the Linux case that's immediately above it; the
Linux case is adding -z defs instead, which is:

      defs
           Disallows undefined symbols in object files.  Undefined symbols
           in shared libraries are still allowed.

Basically, what this does is throw an error at link time if any symbol in
the PAM module isn't defined, which makes sure that you don't have an
external symbol defined but fail to link with the shared library providing
it.  Otherwise, those problems are only detectable at runtime.

Maybe you just meant defs and not muldefs?

> There should be no need for a seperate distribution, as OpenAFS could
> could do all of this, as this PAM routine has no kerberos code, only
> OpenAFS code.

There's no *need* for a separate distribution, but I think it makes life
better for users for the reasons mentioned above.  It is a drawback that
they have to download and compile one more thing, but I think there are
other advantages that outweigh that.

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