3

I am providing an NFS server as part of a collaborative project with another group producing client software over which I have no control. Their software provides file management to its users through a web interface and service, and as a storage backend it uses the underlying filesystem, for which we want to start using NFS.

They have been developing so far against a local filesystem and now that they are trying out the NFS server, they are finding they can't assign the CAP_CHOWN capability to their program. I have not found a way to enable this, but I also haven't found a documented reason this is impossible.

The obvious alternative is to run the chown operation as root, one way or another, as exporting the filesystem to their machine with no_root_squash is not a concern in this situation. However they (understandably) do not want to run their web service as root, so I suppose one kludge would be to create an SUID chown binary on the client and have that called from their web service.

Another alternative may be to map their application’s user to the root user on the NFS server, as if they were operating as root on the client. This seems odd from a security standpoint but seems to me to be a bit of a net gain. But it’s a little awkward on the server side from a maintainability perspective. Also, I don’t know if this is possible; I have only read the idmapd.conf(5) man page and I doubt this is a use case that was considered originally. It may be explicitly disallowed.

I’m continuing to look at this and if I find anything I’ll update this, but if anybody has some suggestions or can enlighten me on capabilities(7) working with nfsd(8), I’d appreciate it.

Update #1: In seeing if there is some granular ACE (access control entry) in NFSv4 ACLs that would need to be loosened, I found there is an o permission that allows ownership. This is promising, but I'm still trying to get this to work: on my system, at least (Ubuntu 16.04) it is accepted syntactically but not applied and has no effect:

[test-nfs] nfs4_setfacl -a A::OWNER@:o testfile
[test-nfs] nfs4_getfacl testfile
A::OWNER@:tTcCy
A::GROUP@:tcy
A::EVERYONE@:tcy
[test-nfs] nfs4_setfacl -a A::OWNER@:r testfile
[test-nfs] nfs4_getfacl testfile
A::OWNER@:rtTcCy
A::GROUP@:tcy
A::EVERYONE@:tcy

I have messed around with some mount/export options on both client and server, but haven't gotten this to work yet.

Update #2: According to this thread, there is no way for CAP_CHOWN to be communicated from client to server, and so has no effect over NFS mounts.

I am trying to determine whether the NFSv4 ACL's ownership permission should work and what I am missing there.

Update #3: According to the same thread above, the permission for ownership in NFSv4 ACLs cannot be properly represented using POSIX ACLs and so requires a richer ACL set. There has been development work on this, which has apparently stalled.

It does not appear I can do what I want to do with the software as-is, and the aforementioned SUID kludge is required, or something like it so that the ownership change operation is effected as root.

The imapd.conf(5) approach I didn't like, but tried anyway, is impossible because static ID mapping only applies in a Kerberos security context, which I'm not using.

So, there is pretty much no answer to this question, I don't think.

  • A brief look at capabilities suggests that you might have to export the mount with looser permissions and then set ACLs on the directories or files that need to be changed by the user, so you're probably right with no_root_squash. For that matter the chown kludge could be viable too. – Simon Greenwood Dec 6 '17 at 7:40
  • @SimonGreenwood, the chown kludge does work, but I'm still hoping for a more elegant solution. I have tried looser permissions on the export but haven't found anything that permits a user to make use of the CAP_CHOWN capability. – Drew Dec 7 '17 at 19:55
  • @Drew did you ever find a solution to this? I'm having this same issue trying mounting an NFS share on a Docker host as some containers require chowning files mounted to them. (i.e. subfolders in the NFS mount are being mounted into various Docker containers that have different ideas about needing to chown) – dalanmiller Mar 27 at 20:43
  • @dalanmiller I never did find a solution to this and I doubt there is one now, though work stopped on this project shortly after this investigation and I haven't had any reason to stay current with NFS development. It's likely NFSv4 ACLs would rely on extended attributes, which also haven't been implemented; RFC 8276 would address this but I have no idea of any implementation. I'm not a Docker expert but I suspect you'll need to find a non-NFS solution. Providing any root access to shared or networked storage carries security risk. – Drew Apr 1 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.