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

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

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

On Sun, 2002-09-01 at 23:56, Trond Myklebust wrote:
> >>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:
> 
>     >> Because, as has been explained to you, we have things like
>     >> Coda, Intermezzo, NFS, for which this is insufficient.
>      > If they only need them at open, and the open is synchronous,
>      > you don't need to copy them.
> 
> Bullshit. You clearly haven't got a clue what you are talking about.
> For all these 3 systems credentials need to be cached from file open
> to file close.
> 
>   YES EVEN NOW, WITH NO CLONE_CRED AND WITH SYNCHRONOUS OPEN !!!!
> 
> On something like NFS or Coda, the server needs to receive
> authentication information for each and every RPC call we send to
> it. There's no state. The server does not know that we have opened a
> file.
But then in the _open_ syscall you don't need to send them from a copy.
However, since you need them in the later syscalls, you need to copy
them to the file structure for the later syscalls in open, but you don't
need to use copied credentials for the operation of opening a file
(assuming it's done synchronously within sys_open).
Anyway this is only relevant to decide whether to always copy uid and
gid or to use copy-write on them and access them with an extra memory
read (to read the pointer to the copy-on-write structure), which is not
the main issue.

BTW, imho a correctly designed network filesystem should have a single
stateful encrypted connection (or a pool of equally authenticated ones)
and credentials (i.e. passwords) should only be passed when the user
makes the first filesystem access. After that the server should do
authentication with the OR of all credentials received and the client
kernel should further decide whether it can give access to a particular
user.
This is off-topic here, though.

> Currently this is done by the NFS client hiding information in the
> file's private_data field. This means that other people that want to
> do write-through-caching etc are in trouble 'cos they have to cope
> with the fact that NFS has its private field, Coda has its private
> field,... And they are all doing the same thing in different ways.
Yes, I agree with the need to provide copy-on-write.
I just disagree with the idea that code should be written to handle
changing credentials and that credentials should be passed as parameters
and I suggest that always copying uid and gid might be better since
accessing uid and gid is more frequent and happens in faster paths than
copying credentials.


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