Re: [PATCH] Initial support for struct vfs_cred [0/1]

[Luca Barbieri <ldb@ldb.ods.org>]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On Sun, 2002-09-01 at 16:10, Trond Myklebust wrote:
> >>>>> " " == Trond Myklebust <trond.myklebust@fys.uio.no> writes:
> 
> >>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:
>     >> For example, rather than this;
>      > <snip>
> 
>     >> you can just do this:
>     >> - uid_t saved_fsuid = current->fsuid;
>     >> + uid_t saved_fsuid = current->fscred.uid;
>     >> kernel_cap_t saved_cap =
>     current-> cap_effective;
>  
>      > But I don't want to have to do that at all. Why should I change
> 
> Just to follow up on why the above 'optimization' is just plain wrong.
> 
> 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.

> The alternative without copy on write is to make a full copy of the
> fscred every time we open a file or schedule some form of asynchronous
> I/O, and hence need to cache the current VFS credentials.
Yes.
Note however that the structure is like this:
struct vfs_cred
{
	uid_t uid, gid;
	vfs_cred_groups* groups;
}

vfs_cred_copy(struct vfs_cred* dest, struct vfs_cred* src)
{
	dest->uid = src->uid;
	dest->gid = src->gid;
	dest->groups = src->groups;
	atomic_inc(&src->groups->count);
}

Of course if you don't need groups you can avoid copying them.
This is efficient if you usually either check the uid and gid or copy
only them (omitting groups).
If instead copying the whole structure is more frequent than the
operations described above, then use reference counting and
copy-on-write for the whole structure, but I don't think that this is
the case.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]