NFS 'sys' security option

[wschmbomrpqg]

Hello everyone.

Under Sharing > NFS there are some security options available.

The documentation doesn't tell much about it:

Only appears if Enable NFSv4 is enabled in Services ➞ NFS. Choices are sys or these Kerberos options: krb5 (authentication only), krb5i (authentication and integrity), or krb5p (authentication and privacy). If multiple security mechanisms are added to the Selected column using the arrows, use the Up or Down buttons to list in order of preference.

Most of them are Kerberos related. But what exactly does this "sys" option?

 

[winnielinnie]

Google brought me here, and I'm still dumbfounded.

I can't find any explanation as to what the SYS security flavor actually is. Is it a basic username/password authentication security, akin to SMB's authentication?

I can only find that SYS is one (of several) possible "security flavors" that are negotiated between client and server, yet it doesn't explain what SYS actually is. (i.e, sec=sys)

Is there anyone who is familiar with this option?

 

[anodos]

SYS == no cryptographic security
Client basically states the uid and gid that it wants, and that's what it gets (with exception of maproot (preventing setting uid / gid to 0) or mapall (which forces to become the specified uid and gid)).

No passwords are involved. If you want authentication with NFS, then you should use NFS + kerberos. There is a _steep_ learning curve here though, and so I think most users who are not already familiar with the nuances of these protocols are better served by just using SMB exclusively.

 

[winnielinnie]

SYS == no cryptographic security
Client basically states the uid and gid that it wants, and that's what it gets (with exception of maproot (preventing setting uid / gid to 0) or mapall (which forces to become the specified uid and gid)).

Not to sound pedantic, but isn't that essentially "none"? Any client can just use UID and GID as 1000, since 1000 is a typical user account's ID, and is usually the default on most PCs (including even TrueNAS, since the first user account you create defaults to 1000, unless you intentionally change it.)

So then restricting an NFS share to a particular IP address is really the only feasible "security", outside going overkill with Kerberos?

 

[anodos]

Not to sound pedantic, but isn't that essentially "none"? Any client can just use UID and GID as 1000, since 1000 is a typical user account's ID, and is usually the default on most PCs (including even TrueNAS, since the first user account you create defaults to 1000, unless you intentionally change it.)

So then restricting an NFS share to a particular IP address is really the only feasible "security", outside going overkill with Kerberos?

It's about par for the course for the 80s/90s. NFSv3 is old, there's a reason why v4 + krb5 was developed.

 

[Patrick M. Hausen]

So then restricting an NFS share to a particular IP address is really the only feasible "security"

The NFS (<= v3) security model assumes a centrally managed pool of servers and workstations with no root access for ordinary users and a central user directory, i.e. NIS, so you have consistent UIDs and GIDs everywhere. NIS (formerly known as YP) was specifically developed to facilitate the deployment of NFS when Sun came up with the diskless workstation concept.

Yes, that *is* old. The first inhouse implementation is from 1984 according to Wikipedia, the first published RFC from 1989.