patch 14/38: CLIENT: add ->setup_read() nfs_rpc_op for async read, part 1

patch 14/38: CLIENT: add ->setup_read() nfs_rpc_op for async read, part 1

[Kendrick M. Smith]

This is a nontrivial change to the NFS client.

Synchronous READ operations are currently done via the ->read() nfs_rpc_op.
Therefore, the synchronous READ path can easily be adapted for NFSv4.  On
the other hand, the asynchronous READ path contains several NFSv3-specific
features, which make it difficult to adapt for NFSv4.

In this patch and the next, we modify the async READ path to be
version-agnostic.  This patch just changes the 'struct nfs_read_data'
so that the v2- and v3-specific parts are moved into a private area,
with room for a v4-specific part in parallel.  None of the logic is
changed.

--- old/fs/nfs/read.c	Wed Jul 24 16:03:17 2002
+++ new/fs/nfs/read.c	Sat Aug 10 22:20:39 2002
@@ -38,11 +38,18 @@ struct nfs_read_data {
 	struct rpc_task		task;
 	struct inode		*inode;
 	struct rpc_cred		*cred;
-	struct nfs_readargs	args;	/* XDR argument struct */
-	struct nfs_readres	res;	/* ... and result struct */
 	struct nfs_fattr	fattr;	/* fattr storage */
 	struct list_head	pages;	/* Coalesced read requests */
 	struct page		*pagevec[NFS_READ_MAXIOV];
+	union {
+		struct {
+			struct nfs_readargs args;
+			struct nfs_readres  res;
+		} v3;   /* also v2 */
+#ifdef CONFIG_NFS_V4
+		/* NFSv4 data will come here... */
+#endif
+	} u;
 };

 /*
@@ -64,7 +71,6 @@ static __inline__ struct nfs_read_data *
 	if (p) {
 		memset(p, 0, sizeof(*p));
 		INIT_LIST_HEAD(&p->pages);
-		p->args.pages = p->pagevec;
 	}
 	return p;
 }
@@ -194,7 +200,7 @@ nfs_read_rpcsetup(struct list_head *head
 	struct page		**pages;
 	unsigned int		count;

-	pages = data->args.pages;
+	pages = data->pagevec;
 	count = 0;
 	while (!list_empty(head)) {
 		struct nfs_page *req = nfs_list_entry(head->next);
@@ -206,13 +212,14 @@ nfs_read_rpcsetup(struct list_head *head
 	req = nfs_list_entry(data->pages.next);
 	data->inode	  = req->wb_inode;
 	data->cred	  = req->wb_cred;
-	data->args.fh     = NFS_FH(req->wb_inode);
-	data->args.offset = page_offset(req->wb_page) + req->wb_offset;
-	data->args.pgbase = req->wb_offset;
-	data->args.count  = count;
-	data->res.fattr   = &data->fattr;
-	data->res.count   = count;
-	data->res.eof     = 0;
+	data->u.v3.args.fh     = NFS_FH(req->wb_inode);
+	data->u.v3.args.offset = page_offset(req->wb_page) + req->wb_offset;
+	data->u.v3.args.pgbase = req->wb_offset;
+	data->u.v3.args.pages  = pages;
+	data->u.v3.args.count  = count;
+	data->u.v3.res.fattr   = &data->fattr;
+	data->u.v3.res.count   = count;
+	data->u.v3.res.eof     = 0;
 }

 static void
@@ -264,8 +271,8 @@ nfs_pagein_one(struct list_head *head, s
 #else
 	msg.rpc_proc = NFSPROC_READ;
 #endif
-	msg.rpc_argp = &data->args;
-	msg.rpc_resp = &data->res;
+	msg.rpc_argp = &data->u.v3.args;
+	msg.rpc_resp = &data->u.v3.res;
 	msg.rpc_cred = data->cred;

 	/* Start the async call */
@@ -273,8 +280,8 @@ nfs_pagein_one(struct list_head *head, s
 		task->tk_pid,
 		inode->i_sb->s_id,
 		(long long)NFS_FILEID(inode),
-		(unsigned int)data->args.count,
-		(unsigned long long)data->args.offset);
+		(unsigned int)data->u.v3.args.count,
+		(unsigned long long)data->u.v3.args.offset);

 	rpc_clnt_sigmask(clnt, &oldset);
 	rpc_call_setup(task, &msg, 0);
@@ -404,7 +411,7 @@ nfs_readpage_result(struct rpc_task *tas
 {
 	struct nfs_read_data	*data = (struct nfs_read_data *) task->tk_calldata;
 	struct inode		*inode = data->inode;
-	unsigned int		count = data->res.count;
+	unsigned int		count = data->u.v3.res.count;

 	dprintk("NFS: %4d nfs_readpage_result, (status %d)\n",
 		task->tk_pid, task->tk_status);

Will NFSv4 be accepted?

[Dax Kelson]

Linus, I'm curious if the NFSv4 patches will be accepted in the near 
future (ie, before 2.6).

I for one would REALLY like to see NFSv4 (actually, Kerberized NFSv4 is 
what I'm after).   I just finished setting up a Kerberized Solaris NFS 
environment with home directories automounted from the clients with 
strong user authentication.

Frankly, the stock (non-Kerberized) NFS security model blows.

The fact that any janitor with a laptop (or any client with a malicious
root user) can nuke all home directories from a standard NFS home
directory server bothers me greatly.

Dax Kelson
Guru Labs

Re: Will NFSv4 be accepted?

[Trond Myklebust]

>>>>> " " == Dax Kelson <dax@gurulabs.com> writes:

     > I for one would REALLY like to see NFSv4 (actually, Kerberized
     > NFSv4 is what I'm after).  I just finished setting up a
     > Kerberized Solaris NFS environment with home directories
     > automounted from the clients with strong user authentication.

     > Frankly, the stock (non-Kerberized) NFS security model blows.

Note: The RPCSEC_GSS (and accompanying kerberos) stuff is completely
independent of NFSv4. It is still in the process of being finalized,
but when it is, it will apply to NFSv2/v3 as well as v4.

RPCSEC_GSS is not an argument for NFSv4...

Cheers,
  Trond

Re: [NFS] Re: Will NFSv4 be accepted?

[Brian Pawlowski]

> RPCSEC_GSS is not an argument for NFSv4...

yes.

But ACL support over the wire is an argument for V4 - and fine grained
authorization coupled to strong authentication makes for a flexible 
security package.

Re: [NFS] Re: Will NFSv4 be accepted?

[Alexander Viro]

On Wed, 14 Aug 2002, Brian Pawlowski wrote:

> > RPCSEC_GSS is not an argument for NFSv4...
> 
> yes.
> 
> But ACL support over the wire is an argument for V4 - and fine grained
> authorization coupled to strong authentication makes for a flexible 
> security package.

Not really.  With the quality of existing userland (Linux, Solaris, *BSD,
NT, etc.) _anything_ more complex than "I'm the only one who can create
or remove objects here" is a big, gaping hole.  Which makes any theoretical
benefits (if any) of ACL-based schemes moot.  Same (to slightly less extent)
applies to regular files.

In other words, if you need something more complex than usual - you are
screwed on the userland side, regardless of the kernel behaviour.

Re: [NFS] Re: Will NFSv4 be accepted?

[Alan Cox]

On Wed, 2002-08-14 at 23:34, Brian Pawlowski wrote:
> But ACL support over the wire is an argument for V4 - and fine grained
> authorization coupled to strong authentication makes for a flexible 
> security package.

ACL works in NFSv2 and nicely in NFSv3 - again the problems Linux has
are the client failing to respect basic NFS rules of operation.

Re: [NFS] Re: Will NFSv4 be accepted?

[marius aamodt eriksen]

* Alan Cox <alan@lxorguk.ukuu.org.uk> [020814 21:13]:

> On Wed, 2002-08-14 at 23:34, Brian Pawlowski wrote:
> > But ACL support over the wire is an argument for V4 - and fine grained
> > authorization coupled to strong authentication makes for a flexible 
> > security package.
> 
> ACL works in NFSv2 and nicely in NFSv3 - again the problems Linux has
> are the client failing to respect basic NFS rules of operation.

there is no over-the-wire specification for sending or receving ACLs
on NFSv{2,3} - hence the server may choose to obey them, but an
arbitrary client cannot set them, or view them.

marius.

-- 
> marius@umich.edu > http://www.citi.umich.edu/u/marius

Re: [NFS] Re: Will NFSv4 be accepted?

[Alan Cox]

On Thu, 2002-08-15 at 07:18, marius aamodt eriksen wrote:

> > ACL works in NFSv2 and nicely in NFSv3 - again the problems Linux has
> > are the client failing to respect basic NFS rules of operation.
> 
> there is no over-the-wire specification for sending or receving ACLs
> on NFSv{2,3} - hence the server may choose to obey them, but an
> arbitrary client cannot set them, or view them.

If you are trying to argue that NFSv4 handles ACL's better you are
preaching to the choir

Re: [NFS] Re: Will NFSv4 be accepted?

[marius aamodt eriksen]

* Brian Pawlowski <beepy@netapp.com> [020814 18:36]:
> > RPCSEC_GSS is not an argument for NFSv4...
> 
> yes.
> 
> But ACL support over the wire is an argument for V4 - and fine grained
> authorization coupled to strong authentication makes for a flexible 
> security package.

and let's not forget such things as getting rid of the representation
of users as UIDs over the wire, as well as delegations (i.e. better
caching == better performance), named (extended) attributes support,
soon-to-come interoperability with a vast array of operating systems,
etc. etc.

marius.

-- 
> marius@umich.edu > http://www.citi.umich.edu/u/marius

Re: [NFS] Re: Will NFSv4 be accepted?

[Trond Myklebust]

>>>>> " " == marius aamodt eriksen <marius@umich.edu> writes:

     > and let's not forget such things as getting rid of the
     > representation of users as UIDs over the wire, as well as
     > delegations (i.e. better caching == better performance), named
     > (extended) attributes support, soon-to-come interoperability
     > with a vast array of operating systems, etc. etc.

Right. I wasn't saying that NFSv4 doesn't have anything going for
it. Just that Kerberos isn't the killer argument: it can easily be
integrated with earlier versions of NFS (and in fact Andy and I had
the basic Linux version running on NFSv3 in February *before* it was
tested for NFSv4).

IMHO the main argument for NFSv4 is the improved support for WANs.

Cheers,
  Trond

Re: Will NFSv4 be accepted?

[Alan Cox]

On Wed, 2002-08-14 at 21:49, Dax Kelson wrote:
> The fact that any janitor with a laptop (or any client with a malicious
> root user) can nuke all home directories from a standard NFS home
> directory server bothers me greatly.

Thats not an NFS2 or NFS3 issue, thats an implementation matter. A
proper NFS credential system prevents that from occurring. You also have
to fix some bogon assumptions in our NFS client too I grant. 

Alan (who is rapidly becoming an intermezzo freak instead)

Re: Will NFSv4 be accepted?

[Dax Kelson]

On 15 Aug 2002, Alan Cox wrote:

> Thats not an NFS2 or NFS3 issue, thats an implementation matter. A
> proper NFS credential system prevents that from occurring. You also have
> to fix some bogon assumptions in our NFS client too I grant. 

Please, do tell.

Dax

Re: Will NFSv4 be accepted?

[Alan Cox]

On Thu, 2002-08-15 at 02:27, Dax Kelson wrote:
> On 15 Aug 2002, Alan Cox wrote:
> 
> > Thats not an NFS2 or NFS3 issue, thats an implementation matter. A
> > proper NFS credential system prevents that from occurring. You also have
> > to fix some bogon assumptions in our NFS client too I grant. 
> 
> Please, do tell.

Ok item #1 you authenticate with the server and get a cryptographic key
for use as credentials. This solves the bad client problem. Kerberos,
gssapi etc will do the job

Item #2 is a bug in our NFS page cache handling. Its not legal in NFS to
assume we can share caches between processes unless they have the same
NFS credentials for the query. The most we can do (and should do) is
that when we think we can reuse a cache entry we issue an NFS ACCESS
check for NFSv3 or for NFSv2 we write it back to the server if dirty
then issue a read for the new credential set.

Re: Will NFSv4 be accepted?

[Dax Kelson]

Q for Linus: What's the prospect of adding crypto to the kernel?

(more below)

On 15 Aug 2002, Alan Cox wrote:

> Ok item #1 you authenticate with the server and get a cryptographic key
> for use as credentials. This solves the bad client problem. Kerberos,
> gssapi etc will do the job

Right, I do understand that Kerberized/GSS NFS is not exclusive to NFSv4.  
However, right now, there is only one way to get Kerberized NFS. The CITI
NFSv4 patches.

Those patches are, in their estimation, ready for inclusion.  NFSv3 
support is "coming down the pipeline". 

I would rather see Kerberos V5 NFS data integrity and privacy support
first (also in the pipeline).  What the current status of including crypto
in the kernel?

> Item #2 is a bug in our NFS page cache handling. Its not legal in NFS to
> assume we can share caches between processes unless they have the same
> NFS credentials for the query. 

I wasn't aware of this.

Thanks,
Dax

Re: Will NFSv4 be accepted?

[J. Bruce Fields]

On Wed, Aug 14, 2002 at 07:51:56PM -0600, Dax Kelson wrote:
> Right, I do understand that Kerberized/GSS NFS is not exclusive to NFSv4.  
> However, right now, there is only one way to get Kerberized NFS. The CITI
> NFSv4 patches.
> 
> Those patches are, in their estimation, ready for inclusion.  NFSv3 
> support is "coming down the pipeline". 

The minimal NFSv4 patches which Kendrick has submitted are ready for
inclusion, but those do not include rpcsec_gss support.  The only
patches which include rpcsec_gss support are patches against 2.4.18, and
they aren't in good enough shape yet, though we hope they will be soon!

--Bruce F.

Re: Will NFSv4 be accepted?

[Linus Torvalds]

On Wed, 14 Aug 2002, Dax Kelson wrote:
> 
> Q for Linus: What's the prospect of adding crypto to the kernel?

For a good enough excuse, and with a good enough argument that it's not 
likely to be a big export problem, I don't think it's impossible any more.

However, the "good enough excuse" has to be better than "some technically 
excellent, but not very widespread" thing. 

Quite frankly, I personally suspect that crypto is one of those things 
that will be added by vendor kernels first - if vendors are willing to 
handle whatever export issues there are, that's good, and if they aren't, 
then the standard kernel cannot really force it upon them anyway.

I personally doubt that NFS would be the thing driving this. Judging by 
past performance, NFS security issues don't seem to bother people. I'd 
personally assume that the thing that would be important enough to people 
for vendors to add it is VPN or encrypted (local) disks.

		Linus

Re: Will NFSv4 be accepted?

[Dax Kelson]

On Thu, 15 Aug 2002, Linus Torvalds wrote:

> 
> For a good enough excuse, and with a good enough argument that it's not 
> likely to be a big export problem, I don't think it's impossible any more.
[snip]
> Quite frankly, I personally suspect that crypto is one of those things 
> that will be added by vendor kernels first - if vendors are willing to 
> handle whatever export issues there are, that's good, and if they aren't, 
> then the standard kernel cannot really force it upon them anyway.

FWIW, Red Hat ships the CIPE kernel module (VPN), so the US export issues
have already been looked at by them.

The US regulations can be found at:

http://w3.access.gpo.gov/bis/ear/ear_data.html

The Export Control Classification Number (ECCN) for the kernel IMHO would
be "NLR" (No License Required) because of the license exception for source
code found in §740.1(e)(2).

Dax

Re: Will NFSv4 be accepted?

[Roger Luethi]

On Thu, 15 Aug 2002 10:35:40 -0700, Linus Torvalds wrote:
> 
> On Wed, 14 Aug 2002, Dax Kelson wrote:
> > 
> > Q for Linus: What's the prospect of adding crypto to the kernel?
> 
> For a good enough excuse, and with a good enough argument that it's not 
> likely to be a big export problem, I don't think it's impossible any more.
> 
> However, the "good enough excuse" has to be better than "some technically 
> excellent, but not very widespread" thing. 

While I'm all for adding crypto to the standard kernel, I contend the
crucial part is not strong crypto, but the API. With a stock kernel that
merely offered rot13 type algorithms and a simple way to add more, we could
sidestep the export issue [1] if necessary and still get important
benefits.

There have been some efforts to find a common platform (e.g. between the
freeswan and the cryptoapi folks recently), but the driving force that
brought us LSM is sorely missing with crypto, although the issue seems less
complex.

I won't comment on the technical excellence of the currently available
solutions, but VPNs and disk encryption (especially for laptop owners) are
quite likely to see (even more) widespread use in the near future. With
Reiser4 it seems there is soon going to be another contender in local
filesystems besides the loopback based ones. RedHat, Mandrake, and SuSE are
already selling products using kernel space encryption (i.e. VPNs and/or
encrypted filesystems).

IMHO the case for crypto in the kernel has already been made. The questions
are rather: what would a kernel crypto facility look like if it was to be
useful for all those projects out there, and who could pull an LSM on this
one?

Roger

[1] Assuming that the times when even crypto _hooks_ were likely a felony
    are gone for good (for many countries anyway). IANAL, obviously.

Re: Will NFSv4 be accepted?

[Trond Myklebust]

>>>>> " " == Linus Torvalds <torvalds@transmeta.com> writes:

     > I personally doubt that NFS would be the thing driving
     > this. Judging by past performance, NFS security issues don't
     > seem to bother people. I'd personally assume that the thing
     > that would be important enough to people for vendors to add it
     > is VPN or encrypted (local) disks.

As I said: one of the main motivations for NFSv4 is WAN support, and
in those environments, strong authentication is a must.

That said, the plan is to also prepare a 'null' authentication scheme
for RPCSEC_GSS (basically using RPCSEC_GSS as a wrapper for AUTH_UNIX)
so that the strong auth can be provided as a simple plugin in case its
inclusion in the kernel would not be acceptable.

Cheers,
  Trond

Re: Will NFSv4 be accepted?

[Oliver Xymoron]

On Thu, Aug 15, 2002 at 10:35:40AM -0700, Linus Torvalds wrote:
> 
> I personally doubt that NFS would be the thing driving this. Judging by 
> past performance, NFS security issues don't seem to bother people. I'd 
> personally assume that the thing that would be important enough to people 
> for vendors to add it is VPN or encrypted (local) disks.

I would have thought that there'd be a big push for merging IPSEC in as it
creates one of those "network effects" but it's still stalled by
politics. I think they're waiting for a written invitation or something.

Is loopback solid enough currently to make crypto over loopback
worthwhile? It's occurred to me that it might be better to move the
translation hooks down to the generic block layer proper so that
things like LVM and iSCSI and brain-damaged bit-swapped IDE could take
advantage of them without the deadlock-prone layering issues of
loopback. Thoughts?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Re: Will NFSv4 be accepted?

[Linus Torvalds]

On Fri, 16 Aug 2002, Oliver Xymoron wrote:
> 
> Is loopback solid enough currently to make crypto over loopback
> worthwhile? It's occurred to me that it might be better to move the
> translation hooks down to the generic block layer proper so that
> things like LVM and iSCSI and brain-damaged bit-swapped IDE could take
> advantage of them without the deadlock-prone layering issues of
> loopback. Thoughts?

I don't know that it is clear which layer should do it. It's certainly 
_not_ clear whether the block layer is the right point, and even if you 
want a hook there I really suspect that upper layers want to pass in 
"context" data to the encryption layer.

In particular, having a global disk security mechanism may not actually be 
a good idea - you may want to have per-file key information, which at 
least implies that the block layer cannot do it alone, and upper layers 
need to pass in different user keys depending on the operation.

In other situations, the proper layer is obviously the stream itself (ie
the "NFS over SSH/Kerberos" kind of thing), but that approach assumes that
you trust the remote end. If you don't trust the remove end, you're back
to wanting per-file encryption (possibly in _addition_ to the stream
encryption), which then ends up implying that you need to have encryption
either at the page cache level or at the actual API level.

(The API level tends to be just done with user-level loadable libraries,
of course, so there may not be much reason for kernel support there.  
Kernel support may or may not be desireable even if the encryption itself
were to be done by the user)

And separate from the actual encryption, you have key management. Even if 
the kernel were to do no encryption at all (as with a user-level library 
approach), I suspect that some people would like to have support for 
keeping track of which keys a process has.

And THIS, I suspect, is one of the major reasons there isn't really all 
that much encryption in the kernel. There's just too much choice, and 
different people really need different things - resulting in it being all 
over the place. 

Clearly some people trust their servers, and just want to have a safe 
conduit over the WAN when they access them. Others don't even trust the 
LAN or the server contents themselves, and want per-file protection with 
private passwords. And both have a good point. It just means that there is 
no "hook". There is a "maze of hooks, all slightly different".

		Linus