Re: Some NFS clients won't mount

vitmaubra@gmail.com <vitmaubra@gmail.com> wrote:

> I did some tests and I'm now pretty sure the problem revolves around
> the point naddy made: Kodi and VLC try to mount my NFS share through a
> non-privileged port. As both Kodi and VLC use the same NFS client
> library (libnfs), I tried to find out a bit more about how it works.
> According to its readme, libnfs uses standard NFS ports when run as
> root and non-privileged ports when run non-root. Here is the relevant
> part of the readme file: "When running as root, libnfs tries to
> allocate a system port for its connection to the NFS server. When
> running as non-root it will use a normal ephemeral port". I find it
> strange that a client library should be run as root in order to use a
> privileged port. My (very poor, I confess) understanding was that only
> server processes should be run as root in order to use privileged
> ports. Anyway, as things stand I can only mount my OpenBSD NFS shares
> if the client is run as root, since the usual way to circumvent this
> problem on the server side (set the insecure flag on exports) is not
> available on OpenBSD and, I hope, won't ever be. As I don't have root
> access to my Fire Stick TV, there is no way to mount my OpenBSD NFS
> shares on it. As I'm no expert on security though, I'd like an opinion
> from you guys regarding this: is it reasonable to require an NFS
> client to be run as root?

Yes, it is very reasonable, because after five decades noone has written
a bug-free NFS server, so this mechanism limiting who can talk to it
makes sense.

More general comment on this matter: The use of reserved ports for
numerous protocols will continue to make sense FOREVER, no matter what
the naysayers say, because there are protocols with insufficient
alternative authentication methods or services you don't want generic
users to startup on a shared system and behave as the cannonical
offering of that service from such a shared system machine. If anyone
things we are wrong, go to IETF and convince then to move http and https
to non-reserved well-known ports *by default*. Anyone who tries this
will get nowhere there, and will get nowhere here either... practical
matters force this.

Sorry.