[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

> >   In addition, the filesystem may cache other data associated with a
> >   particular authentication context.  For example, when we fetch a 
> >file
> >   from the fileserver, it gives us information about what access is
> >   available on that file to the user doing the fetch.  We cache that
> >   information, so we don't have to go back and ask the fileserver to
> >   reevaluate the ACL on every operation.  However, those cached rights
> >   must be associated with the authentication context in which the
> >   original access was done -- otherwise, we might grant some process
> >   too much access to a cached file.

 this would imply that the unix uid _is_ taken into account, yes?

 so in order to correctly obtain the authentication context it would be
 necessary to perform a seteuid or setuid, yes?

 ... and if so, what happens when you have a user-referencing
 structure (NT SIDs, SElinux security contexts, DCE cells,
 etc.) that has nothing to do with unix uids or unix gids?

 [yes, i do realise that you can provide a one-to-one & onto mapping
 table which maps each of these schemes uniquely to unix uids/gids
 on a per-user basis]

 l.