On Sun, 2002-09-01 at 18:40, Trond Myklebust wrote:
> >>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:
>
> >> You are forgetting that the fscred might simultaneously be
> >> referenced by an open struct file. Are you saying that this
> >> file should suddenly see its credential change?
> > No, it cannot be referenced by an open struct file because you
> > copy the structure, not pointers to it.
>
> So you are proposing to optimize for the rare case of setuid(),
> instead of the more common case of file open()?
No, this does not optimize for a setuid. It allows to easily make
temporary modifications to the credentials but that's not the main
focus.
Permanent modifications, if credentials are shared, would need to walk
the shared-cred tasklist and set the propagation flag on all tasks on it
so I'm surely not proposing to optimize for them.
And, in the common case of open, why do you need to copy the structure
to check permissions?
I think that open should just check the current values.
open might want to copy credentials in case you want to do the inode
lookup asynchronously but then it doesn't make sense to optimize for
this since you already have the huge disk read penalty.
BTW, the 2.5.32 open does the check in vfs_permission without copying
anything.
Anyway it's just a 3 long copy plus an atomic inc vs. 1 long copy and
atomic inc.
And if you don't need the groups array, it's just a 2 longs copy that on
some architectures with very slow atomic operations (e.g. sparc) is much
better.
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:14 EST