[OpenAFS-devel] kuserok() checking UID ownership on afs

Troy Benjegerdes hozer at hozed.org
Fri Feb 4 10:33:25 EST 2005


On Thu, Feb 03, 2005 at 08:08:56AM -0800, Russ Allbery wrote:
> Douglas E Engert <deengert at anl.gov> writes:
> 
> > Those are both valid problems,
> 
> > Maybe its time to get rid of the .k5login, it has some security
> > implications where a user can give access to his accounts. Some sites
> > might not like this flexibility.
> 
> > The related problem I would like to solve, is I don't want to have to
> > have the dot files world readable so root on a machine I am on can read
> > the .k5login without a token. and don't have to play all the games of
> > symlinks to a dotfile directory with rl.
> 
> Certainly, use of .k5login should be optional; we patched K4 for years
> locally to allow the sysadmin to indicate that the Kerberos and local
> account namespace should be assumed to be the same for some particular
> realm and the .klogin file should only be checked if it exists, and I
> believe that's now the default behavior in K5.
> 
> However, the functionality still needs to be there.  Use of local account
> names distinct from one's Kerberos principal are in widespread use for
> various reasons.

On Linux, this should be some PAM configurable option, and a PAM module
I don't know what to do for other OS's.

I would be quite happy to get rid of .k5login and get the principal to
local account mapping functionality from either a local text/db file, or LDAP.

On the openafs side of things, I'd like to be able to have AFSid ->
local UID mapping functions as well, so 'ls -l' in someone else's afs
cell can return something intelligent, provided the local admin either
has a mapping daemon running, or has pre-mapped specific remote users.

Maybe the right thing to do is put all this functionality in a
"auth_krb5afs" project that initially would target making a unix PAM
module with a superset of the functionality in the various pam_krb5afs &
pam_krb5+pam_openafs_session modules. This might also be a clean way to
solve my other problem, which is getting tokens at login on a MacOSX
machine from both the GUI and from console.


More information about the krbdev mailing list