* NFS FAQ updates
@ 2004-08-31 12:36 Lever, Charles
2004-09-01 0:24 ` Greg Banks
0 siblings, 1 reply; 15+ messages in thread
From: Lever, Charles @ 2004-08-31 12:36 UTC (permalink / raw)
To: nfs
hi -
i'm considering a series of updates to the FAQ, including adding more
information about NFSv4 and NFS with Kerberos, and removing the 2.2
specific information in the document.
removing the 2.2 items seems possibly controversial, so let me ask here:
does that seem like a reasonable thing to do now?
- Chuck Lever
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: NFS FAQ updates
2004-08-31 12:36 NFS FAQ updates Lever, Charles
@ 2004-09-01 0:24 ` Greg Banks
0 siblings, 0 replies; 15+ messages in thread
From: Greg Banks @ 2004-09-01 0:24 UTC (permalink / raw)
To: Lever, Charles; +Cc: nfs
On Tue, Aug 31, 2004 at 05:36:32AM -0700, Lever, Charles wrote:
> hi -
>
> i'm considering a series of updates to the FAQ, including adding more
> information about NFSv4 and NFS with Kerberos, and removing the 2.2
> specific information in the document.
>
> removing the 2.2 items seems possibly controversial, so let me ask here:
> does that seem like a reasonable thing to do now?
I'd vote: yes.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
@ 2004-08-31 14:11 Lever, Charles
2004-08-31 14:22 ` Quentin Fennessy
0 siblings, 1 reply; 15+ messages in thread
From: Lever, Charles @ 2004-08-31 14:11 UTC (permalink / raw)
To: Quentin Fennessy; +Cc: nfs
[ quentin suggests moving the 2.2-related information to a separate
document ]
one of the problems (which perhaps i should have mentioned in my first
e-mail) is that i don't know of anyone who has the expertise to maintain
the 2.2 FAQ information. it appears somewhat outdated (for instance, it
recommends some extra patches, but have they been included in the latest
2.2 kernels?).
does anyone have a sense of how many people are still running NFS on 2.2
kernels?
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
2004-08-31 14:11 Lever, Charles
@ 2004-08-31 14:22 ` Quentin Fennessy
0 siblings, 0 replies; 15+ messages in thread
From: Quentin Fennessy @ 2004-08-31 14:22 UTC (permalink / raw)
To: Lever, Charles; +Cc: nfs
Lever, Charles writes:
> [ quentin suggests moving the 2.2-related information to a separate
> document ]
I guess I did not write that clearly. Where's my Diet Coke?
I intended to suggest that the 2.2 info be moved to one part of the
document, clearly labelled linux 2.2 related. Once moved, it could be
labelled with an topic specific staleness date. As in "Linux 2.2
information last updated 22 March 2002." Also, specific problem areas
(as Chuck pointed out) could be labelled as out-of-date.
> one of the problems (which perhaps i should have mentioned in my first
> e-mail) is that i don't know of anyone who has the expertise to maintain
> the 2.2 FAQ information. it appears somewhat outdated (for instance, it
> recommends some extra patches, but have they been included in the latest
> 2.2 kernels?).
>
> does anyone have a sense of how many people are still running NFS on 2.2
> kernels?
I don't have a good sense for that. The only 2.2 kernels in my
environment are embedded in devices such as tape drives. And we don't
use our tape drives as either nfs clients or servers.
I'll guess the number is decreasing both absolutely (as people upgrade
Linux) and relatively (as new users install more current releases of
Linux).
--
Quentin Fennessy Quentin.Fennessy@amd.com
Office: 512.602.3873
Cell: 512.694.7489
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
@ 2004-09-20 18:29 Lever, Charles
0 siblings, 0 replies; 15+ messages in thread
From: Lever, Charles @ 2004-09-20 18:29 UTC (permalink / raw)
To: nfs
> [ quentin suggests moving the 2.2-related information to a separate
> document ]
[ or to a different part of the FAQ ]
> one of the problems (which perhaps i should have mentioned in my first
> e-mail) is that i don't know of anyone who has the expertise=20
> to maintain
> the 2.2 FAQ information. it appears somewhat outdated (for=20
> instance, it
> recommends some extra patches, but have they been included in=20
> the latest
> 2.2 kernels?).
i've gotten a few responses to this, mostly "remove the 2.2-related
material". removing it is also my preference. so, as part of a clean
up, i will remove the 2.2-related material in a week or so.
i have a long list of other changes that are waiting for me to get
enough time. if anyone has polite suggestions or constructive comments,
please forward them to me. thanks!
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* NFS FAQ updates
@ 2005-03-13 19:37 Lever, Charles
2005-03-13 20:05 ` J. Bruce Fields
0 siblings, 1 reply; 15+ messages in thread
From: Lever, Charles @ 2005-03-13 19:37 UTC (permalink / raw)
To: Myklebust, Trond, NeilBrown; +Cc: nfs
i'd like to add two new questions, and update one. please review:
When my application uses memory-mapped NFS files, it breaks. Why?
http://nfs.sourceforge.net/index.cel.php#faq_a9
Why should I disable subtree checking on my NFS server exports?
http://nfs.sourceforge.net/index.cel.php#faq_c7
How come lock recovery doesn't work for me?
http://nfs.sourceforge.net/index.cel.php#faq_d7
- Chuck Lever
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: NFS FAQ updates
2005-03-13 19:37 Lever, Charles
@ 2005-03-13 20:05 ` J. Bruce Fields
0 siblings, 0 replies; 15+ messages in thread
From: J. Bruce Fields @ 2005-03-13 20:05 UTC (permalink / raw)
To: Lever, Charles; +Cc: Myklebust, Trond, NeilBrown, nfs
On Sun, Mar 13, 2005 at 11:37:26AM -0800, Lever, Charles wrote:
> Why should I disable subtree checking on my NFS server exports?
> http://nfs.sourceforge.net/index.cel.php#faq_c7
Kerberos doesn't solve exactly the problem that subtree checking
attempts to solve. My attempt at a concise way of putting this (maybe you
can think of a better way):
Use Kerberos and/or NFSv4 when they become available: it may
still be possible for a user of NFS over Kerberos to
access files outside of the exported subtree. However,
it should not be possible for them to fake their identity,
so they should not be able to read files that they do
not have permissions to.
--b.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
@ 2005-03-13 21:41 Lever, Charles
2005-03-13 22:10 ` Trond Myklebust
2005-03-13 22:19 ` J. Bruce Fields
0 siblings, 2 replies; 15+ messages in thread
From: Lever, Charles @ 2005-03-13 21:41 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: nfs
> On Sun, Mar 13, 2005 at 11:37:26AM -0800, Lever, Charles wrote:
> > Why should I disable subtree checking on my NFS server exports?
> > http://nfs.sourceforge.net/index.cel.php#faq_c7
thanks for the review!
> Kerberos doesn't solve exactly the problem that subtree=20
> checking attempts to solve. My attempt at a concise way of=20
> putting this (maybe you can think of a better way):
>=20
> Use Kerberos and/or NFSv4 when they become available: it may
> still be possible for a user of NFS over Kerberos to
> access files outside of the exported subtree. However,
> it should not be possible for them to fake=20
> their identity,
> so they should not be able to read files that they do
> not have permissions to.
hmmm. so what's the difference between not having access to a file, and
having access but not being able to read the file? is it just the
ability to know the file is there? wouldn't that be prevented by not
having access to its parent? or, since the file handle is still good,
lack of permission to look the file up in the new parent would be
inconsequential?
to my mind, this is a very fine hair to split. why, in your opinion, is
it worth mentioning? ie do you have a particular case in mind where
this kind of thing could be important?
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
2005-03-13 21:41 Lever, Charles
@ 2005-03-13 22:10 ` Trond Myklebust
2005-03-13 22:45 ` J. Bruce Fields
2005-03-13 22:19 ` J. Bruce Fields
1 sibling, 1 reply; 15+ messages in thread
From: Trond Myklebust @ 2005-03-13 22:10 UTC (permalink / raw)
To: Charles Lever; +Cc: J. Bruce Fields, nfs
su den 13.03.2005 Klokka 13:41 (-0800) skreiv Lever, Charles:
> hmmm. so what's the difference between not having access to a file, and
> having access but not being able to read the file? is it just the
> ability to know the file is there? wouldn't that be prevented by not
> having access to its parent? or, since the file handle is still good,
> lack of permission to look the file up in the new parent would be
> inconsequential?
The subtree_check option attempts to decide whether or not a file lies
within an exported subtree. If you turn it off, then people can
theoretically try to guess filehandles and gain access to the files
(assuming the access permissions on the file itself allow that).
An example where subtree_check might actually be useful (and where
kerberos won't help you) is if you have /etc and /bin on the same
partition, and you just want to export /bin read-only.
--
Trond Myklebust <trond.myklebust@fys.uio.no>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: NFS FAQ updates
2005-03-13 22:10 ` Trond Myklebust
@ 2005-03-13 22:45 ` J. Bruce Fields
0 siblings, 0 replies; 15+ messages in thread
From: J. Bruce Fields @ 2005-03-13 22:45 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Charles Lever, nfs
On Sun, Mar 13, 2005 at 05:10:11PM -0500, Trond Myklebust wrote:
> The subtree_check option attempts to decide whether or not a file lies
> within an exported subtree. If you turn it off, then people can
> theoretically try to guess filehandles and gain access to the files
> (assuming the access permissions on the file itself allow that).
I wouldn't put too much emphasis on that "theoretically". The root
directory on all my ext2/3 filesystems has inode number 2, and as far as
I can tell guessing the rest of the rest of the filehandle just comes
down to guessing the root device, which on my machines is always
/dev/hdaN for some very small N. Add a few more for people with scsi
and so on, and I bet you could cover most linux NFS servers with a dozen
guesses. Now just lookup and readdir down to wherever you want. Am I
missing anything here?
If the administrator tightened down directory permissions a bit, you'll
be forced to guess filehandles for objects deeper in the filesystem,
which may be a little harder. I wouldn't count on it.
--b.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: NFS FAQ updates
2005-03-13 21:41 Lever, Charles
2005-03-13 22:10 ` Trond Myklebust
@ 2005-03-13 22:19 ` J. Bruce Fields
1 sibling, 0 replies; 15+ messages in thread
From: J. Bruce Fields @ 2005-03-13 22:19 UTC (permalink / raw)
To: Lever, Charles; +Cc: nfs
On Sun, Mar 13, 2005 at 01:41:36PM -0800, Lever, Charles wrote:
> hmmm. so what's the difference between not having access to a file, and
> having access but not being able to read the file?
I was trying to differentiate between the ability to perform IO to the
file and the ability to just get a filehandle for it, but didn't come up
with a good way to say that....
> is it just the ability to know the file is there? wouldn't that be
> prevented by not having access to its parent?
Lack of access to the parent doesn't prevent guessing the filehandle of
the children.
> or, since the file handle is still good, lack of permission to look
> the file up in the new parent would be inconsequential?
Right.
Kerberos allows us to trust that the permissions on files will be
enforced, because (under certain assumptions) the server enforcing the
permissions knows who is trying to access files.
But it doesn't do anything in particular to enforce exports.
> to my mind, this is a very fine hair to split. why, in your opinion, is
> it worth mentioning? ie do you have a particular case in mind where
> this kind of thing could be important?
Hm. Someone on a single-user system that just wanted to export their
homework project might assume that they could safely export
/home/joeuser/compsci101/ without needing to tighten down permissions on
the rest of the filesystem, not realizing that this gives anyone in
their Kerberos realm the ability to read any file in their filesystem
that's world-readable.
Thinking about it a little more, I think I'd just leave out discussion
of kerberos from this section. It really solves a different problem,
and we should still be encouraging people to export only whole
partitions.
--b.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
@ 2005-03-14 17:48 Lever, Charles
2005-03-14 18:09 ` J. Bruce Fields
0 siblings, 1 reply; 15+ messages in thread
From: Lever, Charles @ 2005-03-14 17:48 UTC (permalink / raw)
To: J. Bruce Fields, Trond Myklebust; +Cc: nfs
thanks for your comments, guys. i've simplified C7 a bit, see if it
helps:
http://nfs.sourceforge.net/index.cel.php#faq_c7
> -----Original Message-----
> From: J. Bruce Fields [mailto:bfields@fieldses.org]=20
> Sent: Sunday, March 13, 2005 5:45 PM
> To: Trond Myklebust
> Cc: Lever, Charles; nfs@lists.sourceforge.net
> Subject: Re: [NFS] NFS FAQ updates
>=20
>=20
> On Sun, Mar 13, 2005 at 05:10:11PM -0500, Trond Myklebust wrote:
> > The subtree_check option attempts to decide whether or not=20
> a file lies
> > within an exported subtree. If you turn it off, then people can
> > theoretically try to guess filehandles and gain access to the files
> > (assuming the access permissions on the file itself allow that).
>=20
> I wouldn't put too much emphasis on that "theoretically". The root
> directory on all my ext2/3 filesystems has inode number 2,=20
> and as far as
> I can tell guessing the rest of the rest of the filehandle just comes
> down to guessing the root device, which on my machines is always
> /dev/hdaN for some very small N. Add a few more for people with scsi
> and so on, and I bet you could cover most linux NFS servers=20
> with a dozen
> guesses. Now just lookup and readdir down to wherever you want. Am I
> missing anything here?
>=20
> If the administrator tightened down directory permissions a=20
> bit, you'll
> be forced to guess filehandles for objects deeper in the filesystem,
> which may be a little harder. I wouldn't count on it.
>=20
> --b.
>=20
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: NFS FAQ updates
2005-03-14 17:48 Lever, Charles
@ 2005-03-14 18:09 ` J. Bruce Fields
0 siblings, 0 replies; 15+ messages in thread
From: J. Bruce Fields @ 2005-03-14 18:09 UTC (permalink / raw)
To: Lever, Charles; +Cc: Trond Myklebust, nfs
On Mon, Mar 14, 2005 at 09:48:05AM -0800, Lever, Charles wrote:
> thanks for your comments, guys. i've simplified C7 a bit, see if it
> helps:
>
> http://nfs.sourceforge.net/index.cel.php#faq_c7
I found it a little difficult to understand what you meant by "files
sensitive to access by root" on my first reading:
"If you are still concerned about the minor security
implications described above, export only whole file systems if
the file system contains files sensitive to access by root (such
as setuid binaries)."
And I wouldn't downplay the security concern quite so much. How about
just this?:
"If you need to be certain that clients cannot access files
outside the exported part of a filesystem, set up the partitions
on your server so that you need only export whole filesystems."
A related complaint: the world "filesystem" has a lot of different
meanings. I'm not sure if I'd be able to tell from this answer exactly
which boundaries I could count on being respected by nfsd with subtree
checking turned off. I think "partition" would convey something more
concrete to most administrators. Would it be inaccurate to replace
"filesystem" by "partition" everywhere in this answer?
--b.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: NFS FAQ updates
@ 2005-03-14 18:19 Lever, Charles
2005-03-14 18:25 ` J. Bruce Fields
0 siblings, 1 reply; 15+ messages in thread
From: Lever, Charles @ 2005-03-14 18:19 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, nfs
> I found it a little difficult to understand what you meant by "files
> sensitive to access by root" on my first reading:
>=20
> "If you are still concerned about the minor security
> implications described above, export only whole file systems if
> the file system contains files sensitive to access by root (such
> as setuid binaries)."
>=20
> And I wouldn't downplay the security concern quite so much. How about
> just this?:
>=20
> "If you need to be certain that clients cannot access files
> outside the exported part of a filesystem, set up the partitions
> on your server so that you need only export whole filesystems."
ok.
> A related complaint: the world "filesystem" has a lot of different
> meanings. I'm not sure if I'd be able to tell from this=20
> answer exactly
> which boundaries I could count on being respected by nfsd with subtree
> checking turned off. I think "partition" would convey something more
> concrete to most administrators. Would it be inaccurate to replace
> "filesystem" by "partition" everywhere in this answer?
problem is, i got a lot of this text straight from the man page. :^(
i will see what can be done.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-03-14 18:25 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-31 12:36 NFS FAQ updates Lever, Charles
2004-09-01 0:24 ` Greg Banks
-- strict thread matches above, loose matches on Subject: below --
2004-08-31 14:11 Lever, Charles
2004-08-31 14:22 ` Quentin Fennessy
2004-09-20 18:29 Lever, Charles
2005-03-13 19:37 Lever, Charles
2005-03-13 20:05 ` J. Bruce Fields
2005-03-13 21:41 Lever, Charles
2005-03-13 22:10 ` Trond Myklebust
2005-03-13 22:45 ` J. Bruce Fields
2005-03-13 22:19 ` J. Bruce Fields
2005-03-14 17:48 Lever, Charles
2005-03-14 18:09 ` J. Bruce Fields
2005-03-14 18:19 Lever, Charles
2005-03-14 18:25 ` J. Bruce Fields
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.