Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

Understanding NFS 138

Posted by michael from the things-man-was-not-meant-to-know dept.
LiquidPC writes: "ONLamp.com's Big Scary Daemons section has yet another great new BSD article, this one on Understanding NFS and using it in FreeBSD."
This discussion has been archived. No new comments can be posted.

Understanding NFS More

Understanding NFS

Comments Filter:

  • So who's NFS? (Score:3, Funny)

    by Anonymous Coward on Sunday February 24, 2002 @01:24AM (#3059679)
    RMS's sister?

  • A printer and human friendly version (Score:3, Informative)

    by Shiny Metal S. ( 544229 ) on Sunday February 24, 2002 @01:41AM (#3059727) Homepage
    Here's a printer and human friendly version [onlamp.com], for those of you, who don't like half-screen animated ads inside the text you try to read.

  • What about security??? (Score:4, Interesting)

    by Anonymous Coward on Sunday February 24, 2002 @01:50AM (#3059744)
    I'm appalled that he considers IP address matching to be a way of preventing abuse. Sure, his cable modem is a separate interface so he can use a firewall to block it. But what if you're on a large untrusted LAN and you want to share files between two machines? I have exactly this problem (I have a laptop and a desktop at university) and I'm still looking for a simple yet secure way to share between them without allowing anyone to just spoof the IP address (and preferrably without transmitting my secret plans for world domination over the wire in the clear).

    • Re:What about security??? (Score:5, Informative)

      by autechre ( 121980 ) on Sunday February 24, 2002 @02:39AM (#3059857) Homepage
      As someone else has already mentioned, you could use the Self-certifying File System .

      You could also establish an encrypted tunnel between the two machines using whatever implementation of IPSEC they have (Linux has FreeSWAN, OpenBSD has something built into the kernel, not sure about others). Then you could share stuff however you wanted.

      We're currently using NFS to share our MP3 collections on our private network (behind the firewall/gateway), and it's not a big problem there. But for any network I don't trust (and I'm not very trustworthy :), I'd stay away from it.

    • I've found VTUN works pretty well, and runs on most anything pppd runs on.
    • I agree securing NFS is a hard problem in a hostile environment. Basically, NFS is wide open if you managed to root one machine. A group of my friends at university used to boot machines using linux bootdisk. Then, mimics other guys UID, IP etc to fool the NFS server. If you gain root after login, a clue-up sysadmin should be able to track you down... Boot floppy is the killer here. Well, you can say the computer guys should disable floppy booting option in BIOS. But, they cannot really do much as some student need to boot with floppy occasionally (we are in CSE).

      Simple tricks no longer works when we switched to something more secure, AFS [cmu.edu], in our case.... It is way more advanced than NFS. For example, as a normal user, I can authorise only a few trusted person to have access to one of my designated subdir.

      • Boot floppy is the killer here. Well, you can say the computer guys should disable floppy booting option in BIOS. But, they cannot really do much as some student need to boot with floppy occasionally (we are in CSE).

        You're lucky you're not on any network I've ever admin'd. In my mind, no end-user ever has a need to use a boot floppy. If they do, then that means the machine is broken and, ergo, they should come and find me.

        If they need to use a boot floppy -- perhaps to demonstrate some elegant 1.44MB proof of concept, then they can use a development machine on a development network. (Please read "development" as "I don't give a rat's ass; we blow them away every Friday anyway").

        In a production network, there is no reason that an end-user would ever need to use a boot floppy. Well, there is no legitimate reason that an end-user would need one. In fact, it's difficult to determine a legitimate reason that an end-user would need to use a boot floppy on a development network.

        • In fact, it's difficult to determine a legitimate reason that an end-user would need to use a boot floppy on a development network.
          It makes sense to separate the network into a production and development subsystems... I wish my system admin is as cool as you.

          However, I have some serious doubt whether we can eliminate the need of boot floppy in a development network altogether. Say, you are playing around with RTLinux or other kernel hacks for your project, you just leave with 2 options:
          1) using boot floppy (boot CD, zip etc)
          2) write that directly to harddrive

          Let's forget about bad intentions first. Option 2 needs more attention from sysadmin. (A careless student may overwrite the original linux kernel with his hack... you may need to wipe the the development machine clean before Friday....)

      • Securing NFS is like securing anything else in a hostle enviornment: Do what you can to lock down the protocol. Then make sure you have a nice intrusion detection system (like snort) that can shutdown the services if any funny business is detected.

        Just my $0.02.
    • IP address spoofing (in the classical sense of injecting fake information into the packets you send) is a way of STOPPING certain packets from reaching the intended destination rather than INTERCEPTING packets meant for some destination.

      However, if you mean another machine on the LAN having the IP address as you expect your other machine to have then ok, yes, and especially with DHCP in effect...

      But there is a simple solution: Have each machine only open one port to the outside world, use scp (secure copy) and even run it on a non-standard port and change the password every day if you feel like it.

      graspee

  • Corrections, pointers, and cautions (Score:5, Informative)

    by angio ( 33504 ) on Sunday February 24, 2002 @02:08AM (#3059785) Homepage
    A few things in the article deserve to be clarified. First, Lucas states that "One thing to note is that NFS uses the same usernames on each side of the connection." This is not accurate - NFS uses the same UIDs on both sides of the connection. If you don't have a unified UID space between your machines, you'll have .. issues.

    Second, if you export NFS to the world, you're insane and deserve what you get. If you want remote filesystem access, use a secure protocol like the Self-Certifing Filesystem (SFS) [fs.net]. SFS also avoids completely the problem of having a shared UID space.

    Finally, his advice to mount your filesystems intr is good. But insufficient - also mount them soft, so that filesystem calls will eventually timeout if the server goes poof.

    • Quick pointers to NFS U/GID space solutions:

      * rpc.ugidd - easy, but insecure. can leak u/gid info to untrusted parties. only works with userspace nfs server in linux - don't know about other opsystems.
      * use the same u/gids on every server - almost certainly not an option.
      * use a shared PAM back-end, such as LDAP [openldap.org] (what I use), MySQL [mysql.org], or PostgreSQL [postgresql.org]

    • The "soft" mount option used often to be called the "corrupt" option.

      The problem is that programs rarely check to see if a write() fails after a successful open(). When the file system moves around under them, they can fail to write important data in blissful ignorance. This can lead to files whose contents are essentially broken.

      The fault doesn't really lie with NFS, so much as with the lage body of code which assumes write() calls to a file are more reliable than NFS soft-mounted file systems allow.

      Generally speaking, using soft mount is asking for trouble.

    • re uid/username: mea culpa.

      My original title on this piece was "Introduction to NFS". To the best of my knowledge, ten people in the world truly, deeply understand NFS. Six have won Nobel Prizes, three are in the Institute for the Criminally Insane, and one is not allowed sharp objects and drools on himself a lot. O'Reilly does not seem to like my original titles... ah, well.

      Finally, if Slashdot was going to pick up one of my articles... why, my God, did they choose this one? There are many far more interesting and informative Big Scary Daemons out there... take a look at "Linux Emulation, the Hard Way" for one I'm especially proud of. Sigh. Obviously, they don't want the editorial standard to go above that maintained by other Slashdot authors...
  • One thing to note is that NFS uses the same usernames on each side of the connection. My files are owned by mwlucas on the server, so they are owned by mwlucas on the client. This can be a problem on a large network where users have root on their own machines. To create a central repository of authorized users, consider Kerberos or NIS. On a small network, or on a network with limited administrators, this usually isn't a problem.

    Pre-planning is useful, as always

  • I don't think this article qualifies as "understanding nfs". NFS is a hairy beast, and all this does is get you started from the userland point of view. What makes nfs so hairy is the numerous ways it can fail or at least not do what you expect.

    -Peter
  • I've been looking on Google for about ten minutes for information about NFS I could understand and, just sort of a broad overview of it. Always something germane and informative on Slashdot ;).

  • NFS Howto (Score:4, Informative)

    by I Want GNU! ( 556631 ) on Sunday February 24, 2002 @02:22AM (#3059819) Homepage
    There is already stuff about NFS! The NFS HOWTO can be found at http://nfs.sourceforge.net/nfs-howto/ [sourceforge.net]

    • That's the Linux NFS HOWTO. Although it gives some good background on NFS (and in more depth than the article discussed here) it's pretty Linux-specific when it comes down to the actual setup process. It's not going to give you any FreeBSD-specific information, and so is of limited usefulness in setting up for that system.

      I'm amazed that a comment that's arguably off-topic gets modded up twice as "Informative," but this is, after all, Slashdot.

      -Ed

  • Tip for better NFS performance in FreeBSD (Score:3, Informative)

    by vrgngoddess ( 561460 ) on Sunday February 24, 2002 @03:01AM (#3059898)
    Just a tip... by default, FreeBSD uses conservative NFS mounting options. Note that these work well when trying to interoperate with other Unixes; everybody speaks the lowest common denominator. You can use mount options to augment NFS performance but reduce interoperability somewhat. These options aren't necessary when you're working with one or two clients, but as your NFS installation grows, you'll find them helpful. They may or may not work with other operating systems; it depends on what those OSs support.
  • NFS has a long history of insecurities [209.100.212.5].(Link takes a little while to load...)
    Also in the article he claims: "You can reboot a server and the client won't crash." Maybe not crash but at least with Solaris (in my experience) you hang the entire system during the reboot. Sometimes it comes back and sometimes it doesn't.
    For a secure alternative that runs on *BSD/Solaris/Linux w/(2.4 Kernels) try out:
    Self-Certifying Filesystem [fs.net].
    The authors do warn that it is in alpha stage but also claim they have never lost a file. VERY cool project.

    And of course as the OpenBSD Journal [deadly.org] has noted, SysAdmin Mag [samag.com] is running an article on Tunneling NFS over SSH [samag.com].

  • You CAN have multiple lines for the same partition (Score:5, Informative)

    by fist ( 178568 ) on Sunday February 24, 2002 @04:25AM (#3059987)
    Comments about /etc/exports...
    "There are no identifiers between the components of the line. Yes, it would be easier to read if we could put each shared directory on its own line, but we can't; they're all on the same partition. The FreeBSD team could rewrite this so that it had more structure, but then our /etc/exports would be incompatible with that from any other Unix."

    What?!?! Did this guy even read the man page for /etc/exports? Of course you can have seperate directories from the same partition on different lines!! In the man page they have an example of it! Plus there is this comment lifted directly from the FreeBSD 4.5 man page for /etc/exports.

    "Mount points for a filesystem may appear on multiple lines each with different sets of hosts and export options."

    Michael's articles are usually of excellent quality, but I can't believe how many other mistakes he's made! The article is written to familiarize a "junior" sys admin to NFS, but only teaches them bad habits. Hopefully he'll do a little more research for his future articles.
    • What?!?! Did this guy even read the man page for /etc/exports? Of course you can have seperate directories from the same partition on different lines!! In the man page they have an example of it!

      The article is correct; only mountpoints (and not subdirectories) can be entries in /etc/exports. From the `exports' man page (emphasis mine):

      Each line in the file (other than comment lines that begin with a #) specifies the
      mount point(s) and export flags within one local server filesystem for one or more hosts.


      Furthermore, the only example given in the man page explicitly identifies the directories listed as mountpoints.

      Please don't moderate up comments that sound informational without actually checking your facts first.

      • The article is NOT correct.

        By "mount point(s)" the man page refers to what the client filesystem will use as mount points. Since you've obviously have no experience with NFS I'll give you a quick example of exporting a subdirectory inside a local mount point on its own line. (Notice how /tmp/test is subdirectory in the root filesystem, yet it works as an entry in the exports file!)

        #uname -r
        4.5-STABLE
        # cd /tmp/
        # mkdir test
        # cd test
        # touch hello
        # echo "/tmp/test -maproot=0" > /etc/exports
        # killall -HUP mountd
        # mount localhost:/tmp/test /cdrom
        # cd /cdrom ; ls
        hello
        #

        I believe that the last statement in your post should probably apply to you.
    • Well, just because you can do something, it doesn't mean you should. NFS doesn't export directories--NFS exports filesystems. If you have a FS mounted on /share, and you export /share/somedir, you've actually exported all of /share, even though you may not realize it.
  • I've spent quite some time trying to find a nfs client for windows. Does such a beast exist?

    I've found more than enough shareware/etc... but have been unable to find a open source solution.

    Does anyone know of a free nfs client for windows?
  • ..this intro to NFS is kinda light for /. Understanding NFS -- I believed I was going to be reading about the gushy internal stuff that goes on but in layman terms, but rather, I found stuff that any *nix admin here on /. has known for years. Don't slip. First, that horrible reference to that horrible Google ad-words article, then this.
    • There are a lot of sysadmins here, but I have a hunch that there are more newbies and sysadmin wannabees here. Also, there are many Linux -> FreeBSD converts that could use this information. (I don't know how similar NFS on those platforms are, but I'm sure there are some differences).
  • NFS rocks. Coming from the PC world, I was shocked when I discovered how long this useful standard has been around, and how compatible the implementations are... A little while ago I added an old SGI Indy to my Linux network. I tried mounting my primary NFS share on it, expecting to spend several hours troubleshooting in IRIX before it would work. And whaddya know, it came up perfectly the first time =).
    • A hole in one every time. You can't beat such a record with SMB (Windows shares) w/o having an MSCE (connecting win98 machines with windows 2000 is not always a "turn key" thing.. *grumble* what's up with those Redmond freaks?)

  • Security (Score:3, Informative)

    by NWT ( 540003 ) on Sunday February 24, 2002 @05:50AM (#3060100) Homepage
    For those who are interested in a more secure NFS, i found an interesting article about encypted NFS (via openssh) It's a good read, and really interesting! Unfortunately it's written for Linux, but it's easy to adapt it to *BSD. Check it out here [samag.com]!
  • The article makes quite an interesting read. I enjoyed reading it, and if you want even more information, read this [onlamp.com].
  • "You can reboot a server and the client won't crash. It won't be able to access files on the server's export while the server is down, but once it returns, you'll pick up right where things left off. Other network file sharing systems are not so resilient."

    From regular personal experience, I can state that NFS is hardly so robust under HPUX.... Is BSD really this foolproof?

    • I've only had NFS on my FreeBSD box at work for a short while. But I've had it on my Solaris box for three years now. For a while last year the server would crash and burn every hour or two. A very horrible situation that only got resolved when we threatened to send to the servers back to Sun via patriot missile. This went on for a week. Not once did it cause any of the Solaris clients to buckle or fold.

      p.s. I suspect that a certain Sun rep deliberately sabotaged our servers in order to generate support calls. Obviously he is no longer a Sun rep.


  • I had alot of fun with NFS during my Univerity years. Sure it has some nice features as it's lightning-fast and stateless but it's totally unsecure, period.

    The NFS server has two parts, the authentication part and the data-server part. The authentication part authenticates based on the IP address of the requester, if successful, it will send the requester the 'key' for the export.
    After that, anybody can use that key to request files from the data-server part. And from any IP address!!

    There exist a very nice ftp-like tool that lets you play with NFS systems, enter the key manually or use the UID overflow bug to get root privs. And this is only the beginning of the fun !!

    Trust me, "Don't use NFS" unless you are running it on a network that is not connected to the rest of the world, and you trust everyone that has access to this network.

    • Use IPSEC authentication (AH or ESP if you also need encryption). Doesn't get much more secure than that.. The rest is your fault.. ;)


      • Use IPSEC authentication (AH or ESP if you also need encryption).

        Try that for 3000 clients and your performance is toast !

        • Try that for 3000 clients and your performance is toast !

          1. Cluster your export points
          2. Use hardware accelerated encryption devices
          3. Ask yourself: do these 3000 clients really need access? And what part of the local file system do they need access to? I realize that querying 3000 users for their purposes is a bloody hard job now, but it should have been done in the first place. Follow the principle of least privilege.

          For an organization with 3000 external clients, security shoult be at the top of the TODO-list. Finding a hacker/spoofer among 3000 clients is like finding a needle in a haystack. If this scenario is yours, then please reconsider some major security face lifts...


          • What you are proposing is throwing huge amounts of money out the window to fix a broken protocol.
            Have you *any* idea what 3000 encryption hardware accelerators might cost ? (+ servers)

            The "Correct" way, from every standpoint is simply not to use NFS, but some other protocol that has the security parts you need. For example, as long as you can protect the authentication credentials, encrypting the contents might not not be as important.

            But, many have also taken the "more money" way, and the simplest path to follow there (from an administrational point of view) is simply to use microsoft.

            The scenario is not mine, but not many years ago, a lot of universities had this setup. There are a LOT of hackers there, and many have switched to microsoft CIFS now.

  • Check out the latest SysAdmin Magazine [sysadminmag.com]. It has an article about securing NFS using SSH [openssh.org].

  • Personally I recommend never using NFS. Heck, I wrote a paper [time-travellers.org] about it. It's a bit old, and doesn't cover NFSv4. But of course, NFSv4 doesn't address the basic issue of using the wrong model for the problem, so that's not a big deal. :)
    • > Heck, I wrote a paper [time-travellers.org] about it. It's a bit old, and doesn't cover NFSv4.

      Old? It's ancient. Virtually every point
      you have in your little paper is nonsense,
      at least when it comes to commericial grade
      NFS implementations.
      • Virtually every point you have in your little paper is nonsense, at least when it comes to commericial grade NFS implementations.

        I'd be very interested to know which points are nonsense, and also what you consider a "commercial grade" NFS implementation. Remember that a lot of these issues are client-side related, and I'm especially not sure what a "commercial grade" NFS client is.

        My experience with NFS is limited to Network Appliance, Solaris, Linux, BSDi, SCO, and Digital Unix (as well as some early Windows NFS applications).

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close