Hacker News new | past | comments | ask | show | jobs | submit
steveBK123 | on: Mounting Git commits as folders with NFS
NFS.. stop right there
mmh0000 | parent
You're being downvoted, but, seriously... NFS is a joke for anything outside of an enterprise setup with a bunch of ancillary support services in place.

The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever:

  Client: Hi, NFS server, I'm Bob! UID=1000
  Server: Hi Bob! Here's access to all of Bob's files! I trust you and don't need a password or anything!
  Client: Thanks!!!
Some of you may nitpick and say, "well ackkkuallyy, NFS supports authentication through GSSAPI/krb."

And to you, I say, that's crazy! Setting up Kerberos just to authenticate users for access to my Linux ISOs is a crazy large requirement! Sure, it might make sense for an enterprise that already uses Kerberos + LDAP + NFS + certificate management, but for everyone else, that's a lot of infrastructure to set up and maintain for what should be BASIC functionality.

EDIT

ALSO!!! Why the fork does NFS run as a kernel module (nfsd)!? Shouldn't that be an external daemon!? Who the heck thought any of this was a good idea!?

  <sarcasm mode> 
    Dev1: Here's a great idea! Let's run an insecure network server in Kernel space! 
    Dev2: OMG! You're so smart! Let's also exclude any encryption!!!
 </>
//end rant of an old, bitter Linux sysadmin
chungy | root | parent | next
Funny part is, that NFSv4 supports SIDs for user authentication, but the Linux implementation leaves it out (among all the other ACL features) simply on the basis that Linux doesn't support them at all.

The FreeBSD, Solaris, Mac OS X, and Windows (yes, even Windows) implementations of NFSv4 are fully featured with this stuff.

feurio | root | parent | next
> Setting up Kerberos just to authenticate users for access to my Linux ISOs is a crazy large requirement!

Export as read only?

projektfu | root | parent | next
Will this matter if it's running on localhost and only accessible to the users there? She's just using it as a stand-in for FUSE.
mmh0000 | root | parent
To be clear: I am not criticizing the use case in the article. It's a silly, fun, and creative hacking together of technology.

I am criticizing NFS as a whole, and specifically its Linux implementation.

nine_k | root | parent | next
Does this mean that I can connect to an NFS server saying my UID=0 and get local root?
mmh0000 | root | parent
Usually, no. NFS defaults to "root_squash," which silently changes UID=0 to the UID of the `nfsnobody` user.

However, in the /etc/exports file, you can (but shouldn't) add the share option "no_root_squash" which disables that.

So, root access is slightly protected. But all other users are wide open.

IshKebab | root | parent | next
Even worse is the .nfs "silly renaming" nonsense. I was under the impression that NFSv4 fixed that but someone told me it doesn't.
steveBK123 | root | parent | next
So many battle scars from NFS in production for me as well.

Wish the downvoters all the best in their future NFS endeavors.

skydhash | root | parent
> The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever

Doesn’t the secure option require ports only a root user can bind too? And you can always create secure tunnels if the physical network is insecure.

mmh0000 | root | parent
Sure, if you (the admin) have full control over the NFS server, the network, and the client devices, NFS can be secure with the help of Kerberos. But this isn't a simple thing. A Kerberos server needs to be set up, Kerberos clients need to be configured on the NFS server and client, tickets need to be issued, firewall ports need to be opened, and user accounts need to be centrally managed. That's all fine for an Enterprise.

Now, how about this common scenario: I want to run a file-sharing server on my network. I want a random "friend" to come over and grab a copy of a file, but I don't want them to see any other files on the NFS server.

So, the "friend" has root access on their device. They can just log in and lie to the NFS server, claim they're my UID, and see all my files that I didn't want them to access. Configuring KRB in that scenario is totally impractical.

loading story #48227136