Chris's Wiki :: blog/linux/NFSClientIDRemapWish

A feature I wish the Linux NFS client had: remapping UIDs and GIDs

July 4, 2016

My office workstation is a completely standalone machine, deliberately not dependent on, say, our NFS fileserver infrastructure. As a sysadmin's primary machine, there are obvious motivations for this and it's not something I'm ever going to change, but at the same time it does have its drawbacks and it'd be nice to sometimes NFS mount my fileserver home directory on my workstation.

Unfortunately there is a little but important obstacle. For peculiar historical reasons, the UID and GID of my local workstation account are not the same as on our fileservers (and thus our Ubuntu servers and so on). My login name is the same so things like SSH work fine, but NFS cares about the actual UID and GID and I wind up out of luck as far as NFS mounts go.

In theory the solution to this is NFS v4. In practice we don't use NFS v4 now, we're very unlikely to add NFS v4 any time soon for general use, and there is exactly zero chance that we'll add NFS v4 to our environment just so that I can NFS mount my fileserver home directory on my office workstation. Put bluntly, there are much easier solutions to that particular problem, ones that put all the work on my head where it rightfully belongs.

Hence my wish that the NFS client would support remapping UIDs and GIDs between the NFS server's view and the local Unix's view. In my particular situation I'd even be happy with a mount option that said 'always tell the server that we're UID X and GID Y', because that's all I need.

There's a pro and a con argument for doing this in the NFS client instead of the NFS server. The pro argument is that it's easier to scale this administratively if you can do it in the client. If it's done on the client, only the person running the client has to care; if it's done on the server, the server administrators have to be involved every time another client needs another UID or GID remapping.

The con argument is that NFS v3 'security' is already leaky enough without handing people a totally convenient client side way of subverting it totally (well, if you have root on a client). Yes, sure, you can already do this in a number of ways if you have client root, but all of those ways take at least some work. This feature would make it trivially easy, and there's a benefit to avoiding that.

(I expect that the real answer here is 'the Linux NFS maintainers have no interest in adding NFS v3 UID and GID mapping code in either the client or the server; use NFS v4 if you need this'. On the other hand, they did add NFS v3 server support for more than 16 GIDs.)

Comments on this page:

By Anon at 2016-07-05 01:58:40:

If you are using a userspace NFS mounter (http://unfs3.sourceforge.net/ ) you might have access to map_static. In the grand scheme it's a pity that using things like using libnfs to re-serve up shares via FUSE isn't mainstream...

By Ewen McNeill at 2016-07-05 02:11:27:

I find myself missing the footnote explaining why you don't change the UID/GID of your workstation. Obviously that'd require changing the UID/GID of lots of (local) files already on your system, but that's time consuming but not conceptually difficult. (Eg, some variation on find / -uid ${OLDUID} -print0 | xargs -0 chown ${NEWUID}; and the same for gid, but separately, to take care of files where uid and gid aren't both set.) Plus of course you would need to log out and log back in again, at least, to ensure all processes were running with the new UID/GID.

Certainly that's been my solution to that "one system has mismatched UID/GID" issues in the past, where it's mattered (NFS...). Even where $OS_A and $OS_B had different ideas of starting UID/GID for "regular users", there was usually enough wiggle room to make it work. (Indeed some of my systems still have the UID/GID of my first Slackware install 20ish years ago, despite being installed much later, for that and "Grandfather's axe" reasons.) Obviously it is easier to do before there are lots of files with the "wrong" UID/GID. But it's merely messy and inconvenient to do so later, not impossible.

Ewen

PS: Random thought, assuming a single-user desktop with its own static IP(s): all_squash and anonuid/anongid, with an export just to your desktop IP? (That's obviously a one-user-per-IP work around though.)

From 31.17.248.110 at 2016-07-06 13:15:16:

Honestly, for the "I just need to look at some files in there occasionally" case I have just given up on any setup and/or configuration and use sshfs.

Of course it comes with all the caveats of FUSE, but on a local net it's fast enough for most things, requires no brain power to set up and if I really need to do something involving a lot of I/O, I can always ssh into the other end and do it locally.

By cks at 2016-07-07 10:56:04:

Ewen: most of my reluctance is that it's a lot of (disruptive) work, especially since I probably won't normally do NFS mounts on this machine. I also have things like tar archives and filesystem backup images and so on that would now have the wrong UID and GID in them, and those I can't renumber; at the best I could fix them after unpacking them (if I ever do that).

Written on 04 July 2016.

«	An irritating little bug in the latest GNU Emacs Python autoindent code

It turns out that viruses do try to conceal their ZIP files