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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 [email protected]
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Mar 14, 2005 at 10:19:11AM -0800, Lever, Charles wrote:
> problem is, i got a lot of this text straight from the man page. :^(
Man page patches would certainly be welcome too.... Thanks for working
on this.--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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 <[email protected]>
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs