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

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Sat Aug 31 2002 - 17:30:23 EST


>>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:

> Then the rest of the code doesn't need to know at all that
> credentials are shared and is simpler and faster. We have
> however a larger penalty on credential change but, as you say,
> that's extremely rare (well, perhaps not necessarily extremely,
> but still rare).

What if I, in a fit of madness/perversion, decide to use CLONE_CRED
between 2 kernel threads (i.e. no 'kernel entry')?

Leaving CLONE_CRED aside, please do not forget that most of the
motivation for vfs_cred is the need to *cache* credentials.
This is something which we already do today in several filesystems:
Coda, Intermezzo, NFS, to name but the most obvious.
The result of the lack of a VFS-sanctioned credential is that we have
to use 'struct file' as a vehicle for passing credentials in, for
instance, the address_space_operations, and that each filesystem ends
up having to keep its own private copies of those credentials in
file->private_data.

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:34 EST