lkml.org 
[lkml]   [1999]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [NFS] Re: 2.3.30 linuxNFS import is broken (Screwed up NFS/RPC credentials)

(I added nfs-devel to the Cc list as there might be some people there
who can comment on how this works in other OSes??, and Stephen Tweedie
because of the last paragraph)

On Tuesday December 21, trond.myklebust@fys.uio.no wrote:
> >>>>> " " == Alexander Viro <viro@math.psu.edu> writes:
>
>
> >> Arrgh. Somebody has messed about with the API for readpage and
> >> writepage, so that they no longer pass the file pointer!
>
> > Damn! Could you tell me _where_ did they use it?
> > write_one_page() still gets the struct file*, if that's what
> > you are thinking about. readpage() and writepage() are _full_
> > _page_ accesses. Nothing to merge here, AFAICS.
>
> Let me explain: The problem is that NFS relies on the user sending the
> RPC authentication each and every time we access data on the
> server. In order not to get a permissions error suddenly if the user
> changes euid while s/he is reading/writing to the open file, we
> therefore want to use the same RPC authentication info throughout the
> file's lifetime. Ideally that means taking the RPC auth info that was
> valid when opening the file (since this is more or less in line with a
> POSIX filesystem's behaviour with permission checking at file open
> only) and caching it somewhere.
>
> The most practical way of implementing this policy is therefore to
> hide the RPC auth in the file descriptor structure (I use the private
> data field), and pass that info via the file pointer to
> readpage/writepage/whatever else needs it.

There are some really interesting issues here...

Firstly, it is worth noting that there are two distinct but related
contexts for permission checking in NFS. One is between the process
and the "agent" (which is my name for the client filesystem code) and
the other is between the "agent" and the server.

If the agent has a file cached, then it needs to know how to grant or
deny access without trying the access against the server. For NFSv2,
the best it can do is examine the Unix permission bits. For NFSv3
(and v4) there is the "ACCESS" call which does exactly the test
required.

When the agent needs to access data on the server it needs to have
credentials to give to the server to authorise the access. Currently
in Linux these are the credentials of the process doing the access,
though Trond wants to change this so credentials get cached in the
file handle at open time (which is a good thing).
However it is worth noting that the credentials used to fill or flush
the cache do not *need* to reflect the principal who is requesting the
access. This is particularly apparent with NFSv3 and unstable
writes:

Suppose I open a file and write bytes 0-127. Then you open the file
and write bytes 128-511. Both of these go to the server as UNSTABLE
writes, presumably with my and your credentials respectively.
But suppose the server restarts before we do a commit - the data has
to be written again. Whose credential is used? Presumably the
credential of whoever does the fsync/close which forced the commit.
But in a very real sense it doesn't matter as long as it is a valid
credential.

So, what the Linux NFS client could do is:
Store credentials in the file handle and open time.
Copy them into a per-inode cache on each read/write request.
Use any appropriate credential out of the per-inode cache when
read/writing data to/from the server.

Most of the time there would only be one credential (or credential
reference) in each inode. Possibly you would only need to store
three: The most recent credential with read access, the most recent
with write access and the most recent with "ownership" access (though
that last one might not be needed).


Thinking more about keeping UNSTABLE writes in the client cache, it
occurs to me that there would need to be some way for memory pressure
to encourage the client to commit cached writes so that memory can be
freed up, much like Stephen Tweedie wants for his journalling
filesystem? Is there really a similarity here or am I imagining it?
Trond: does your NFSv3 code allow memory pressure to force commits of
unstably written data and if so, what credential do you use? (another
case for storing the credential in the inode?)

NeilBrown

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

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.157 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site