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. :-)

Read above.

Joerg

> 
> Take care,
> 
> Bill
> 
>