Slashdot Mirror

← Back to Stories (view on slashdot.org)

NFS/NIS Recommendations for Windows?

Posted by Cliff on from the playing-nicely-on-the-network dept.

Fembot asks: "The Samba team are doing a great job, but I can't help but feel that making Unix machines serve Windows-based protocols is the wrong approach. Back in the days of Windows95 it shipped with an NFS client on the CD which could be installed optionaly. Are there open source (or even just free as in beer) NFS clients for Windows 2000/XP, and is it possible to authenticate users on Windows desktops via NIS?"

6 of 48 comments (clear)

  1. Linux Interaction Kit by Speedy8 · · Score: 5, Interesting

    Think of how cool it would be if HP, DELL, Alien Ware, etc. shipped all of their computers with a Linux interaction kit full of programs that would allow windows users to interact with Linux boxes using opensource protocals. The computers would still interact with windows boxes int he normal way but could use the open source methodes to.

  2. Security considerations by plsuh · · Score: 3, Interesting

    Another factor involved in using NFS with Windows clients is the security model involved. To expand on Jeremy Allison's excellent comment, the NFS security model relies totally on the UID at the client. Since there is no native concept of a UID in Windows (plus the fact that the Win9x branch doesn't have good user privileges separation in any case), this means that you need a separate login from the Windows PC to the NFS server, using a system known as PC-NFS originally created by Sun. There is an open source pcnfsd daemon that will handle this at the server end, but the client piece is not free, and the whole thing is a PITA to set up, and is one more thing that can go wrong on a fragile Windows client system. Much better to use Samba on the server and not have to rely on yet another skanky layer. (Been there, done that, have the therapist bills to prove it :-P)

    FWIW, the Mac OS up through version 9.2 has pretty much the same set of issues. Mac OS X, being Unix-based, has NFS server and client support natively.

    --Paul

    1. Re:Security considerations by mjstrom · · Score: 2, Interesting

      Yes, the do have SIDs. However, mapping SIDs to UIDs is not an easy job especially since SIDS are really a GUID (like {0000002F-0000-0000-C000-000000000046}) which are too long to be cleanly mapped in a UID. Take a look at the Samba's Winbind project here for some more details about the problems involved.

      The end result is that there isn't a clean mapping between the two domains. And the implementations of NFS for windows that I have seen have been hackish at best and disfunctional at worst.

      Using the windows protocols (CIFS or whatever it is being called these days) may be the best option.

    2. Re:Security considerations by 0x0d0a · · Score: 3, Interesting

      To expand on Jeremy Allison's excellent comment, the NFS security model relies totally on the UID at the client.

      Might this have changed when they moved to NFSv4? It uses GSSAPI, which presumably means it uses Kerberos principals instead of UIDs to identify users on a client machine.

      --
      May we never see th
    3. Re:Security considerations by SN74S181 · · Score: 2, Interesting

      I ran into some interesting 'UID at the client security' issues at a place I recently worked. I had an NT box, and I threw a copy of Microsoft's Interix POSIX subsystem on the machine. Through coincidence I discovered that I could rsh into any of the Solaris boxes at the company. What I noticed most significantly was that it wasn't asking for a password at all. So, as an experiment (I had the admin password on the NT box, which was my desktop machine) I created an NT account on the machine with a co-worker's UID. *poof* I could rsh into any Solaris box, and I had their account privledges.

      I quietly backed out without doing a thing, but it made me a little nervous. The company in question makes implantable medical devices, and it would have taken me a minute or two longer to make changes to firmware code in development for said.

  3. Re:Good reason for this.... by SN74S181 · · Score: 2, Interesting

    People are always saying 'NFS really sucks in general' and it's hard to tell why they say so. It might have to do with poor implementations of NFS on Linux that I've heard mentioned. I have an NFS server here on the home network that's rock steady and serves as a primary 'waypoint' for all the Unix boxes. They're all NetBSD and Solaris boxes, so maybe that's why I haven't had any problem.

    Is there a short digest version of what's so bad about NFS on Linux that someone can reiterate?