[OpenAFS] home on afs woes

[Douglas E. Engert]

I have found this discussion very interesting, and it appears many sites
are living with the "l" symlinks for .k5login to a directory with "rl".
mostly because that is the simplest thing to do.

But after reading Jeff Hutzelman's note from earlier today, maybe the
problem is not with AFS but with Kerberos. Kerberos is relying on the system
for integrity protected access to a file system when it may not be protected.
Its not just an AFS problem, home directories in NFS may has the same problem.

Maybe there should be a way to turn off ~/.k5login and provide
the mapping in other ways. The auth_to_local in the krb5.conf is a start.
But looking at the code in kuserok.c in MIT and Heimdal they appear to check
for ~/.k5login before checking for auth_to_local in the krb5.conf.

Some other replacements to .k5login include the ANAME_DB code,
or having a k5login directory with all the user's .k5login files on
a local file system, or some NIS or ldap service.

We might all be better off if the admin of the server had control over the
.k5login, rather then the users.

Many of us may have all become to complacent with the use of the .k5login.




Lester Barrows wrote:

> On Thursday 05 January 2006 7:32 am, Ken Hornstein wrote:
> 
>>Given the choice between files possibly being world-readable and users
>>having to expose their password for every login (even if you're
>>encrypting the session, we've learned the hard way that isn't enough
>>anymore), we decided to go with the former.  As always, to each his or
>>her own.
>>
>>--Ken
> 
> 
> This appears to be a security decision based primarily on a technical 
> limitation in AFS. The per-directory ACL limitation itself was more or less 
> what I was discussing, as it has caused me more than its share of headaches. 
> If I could place an ACL on a file and have it alone be readable/listable by 
> the authentication process, that would be ideal. It's great that a world 
> listable/readable top level home directory configuration works for your 
> environment's security requirements, and it certainly saves a bit of work. It 
> just isn't sufficient to comply with our security plans.
> 
> Best regards,
> Lester Barrows
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444