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);
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
>>>>> " " == Dax Kelson <[email protected]> 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
> 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.
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.
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)
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.
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
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.
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
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.
* Alan Cox <[email protected]> [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.
--
> [email protected] > http://www.citi.umich.edu/u/marius
* Brian Pawlowski <[email protected]> [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.
--
> [email protected] > http://www.citi.umich.edu/u/marius
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
>>>>> " " == marius aamodt eriksen <[email protected]> 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
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
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
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.
>>>>> " " == Linus Torvalds <[email protected]> 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
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.."
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