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.
