[OpenAFS] home on afs woes

[Russ Allbery]

Sergio Gelato <Sergio.Gelato@astro.su.se> writes:

> This is straying off-topic, but I'd argue that the default behaviour of
> a PAM module should still be the correct one: call krb5_kuserok() from
> pam_sm_acct_mgmt() only. Then one can add options to work around bugs in
> important applications.

The problem with doing this is that if you deploy a PAM module with this
configuration, the local system administrator that's using xlockmore and
has local accounts that happen to have the same username as a Kerberos
principal but are not the same person (an extremely common configuration;
there are hundreds of systems in this state around Stanford) immediately
gets a security hole.  And they have to know to add weird options to the
pam_krb5 invocation in order to plug it.

I don't like defaulting to being insecure.  :/

> As far as the screensavers' not running the account stack, I'd be more
> worried about what happens when a Kerberos password has just expired
> than about krb5_kuserok() being skipped: after all, the initial login
> must have run the account stack successfully.

The screen savers that I've looked at actually explicitly don't call the
account stack (or call it and ignore its return status) because they don't
want to lock out users with expired accounts.

Don't ask me; I don't write the applications, I just try to hack PAM
modules to work with them.

(The other pain in the ass are screen savers like xlockmore that also
don't call either pam_setcred or pam_open_session -- why are there two
APIs when most PAM modules appear to treat these as synonymous? -- which
means that they don't refresh Kerberos tickets and AFS tokens.)

>> >I don't see a good solution to this, unfortunately.  I wish that AFS
>> >supported the directory lookup semantics supported in Unix with execute
>> >but no read, but I can see why that would be rather hard to do.

> Would it buy you all that much? We're talking about well-known file
> names here, it's easy to test for their existence one by one even
> without the convenience of readdir().

I personally don't care that .k5login is world-readable.  That's fine by
me.  I just care that I have to make my home directory listable in order
to support it.

Of course, I personally don't actually do that; I use a trick that we've
been recommending to advanced AFS users for years at Stanford.  My
"official" home directory is completely world-readable, but all that's in
it is the basic files required for authorization and a stub shell
initialization file that cd's to a subdirectory called home, sets HOME,
and then sources my real shell initialization files.  Works like a charm
(at least once you've patched all the programs that don't honor $HOME in
the environment, but we did that years ago and submitted all the patches
back and for the most part everything works now).

Explaining that to the average user is hard, though.

> That seems to call for a host.hostname entry in PTS and a way for sshd
> etc. to obtain an AFS token for that, discarding it (e.g. by changing
> PAGs) before control is handed to the user... OK, I see that Jeffrey
> Altman has beaten me by a few minutes.

Yeah, Jeff's idea is an interesting one.  It's a lot of PTS IDs, but I
guess that isn't really a scarce commodity.

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