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
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
* 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
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
* 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
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == 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
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs