Subject: Re: BSD Authentication
To: NetBSD-current Discussion List <current-users@NetBSD.org>
From: Joerg Sonnenberger <email@example.com>
Date: 08/29/2003 15:36:55
On Thu, Aug 28, 2003 at 10:15:44AM -0700, Bill Studenmund wrote:
> The reason it has to be loaded in the client app is that it is a
> per-process entity. You are loading what that individual process can use
> to access AFS. The cache is inherited across fork() AFAIK.
The AFS credential as per-process entity is entirely valid and necessary to
support users having different accounts in the same realm e.g. Joe User and
Joe Admin. That doesn't mean is has to be a _local_ per-process entity.
> So while yes there are other ways to do this, they all strike me as uglier
> or scarier than what AFS is doing. I don't want any(*) other program able
> to see my process's credential cache or able to touch it. Not even
> anything owned by root. (*) unless the two processes are inherited from
> the same login and are thus using the same cache. :-)
That has scheme has the advantage of being simple to implement with a small
kernel footprint and works well with PAM-like authentication. It has it flaws
too. The most important problem arises with long-running processes. You cannot
renew the token e.g. of a daemon process without entering its domain.
Think about it. If you have the possibility to alter (not read!) the credentials
associated with a process, BSD auth can be used with AFS and kinit works too.
> So for what AFS is doing, the sanest thing to do is to actually load the
> tokens from within the client that will be using them. i.e. what AFS is
> doing is a rather sane thing to do. :-)
> Take care,