> > 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
