>> A possible workaround is to have the software call an SUID copy of `chown` >> that is only available to the user ID of the web service, but this is less >> desirable. > > I think this may be your only solution. NFS/RPC has no way to communicate permission CAPs to the server. > > If CAPs could be user based as well as process based, then you could grant the web service's user ID the appropriate CAPs on the server. > > NFS v4 ACLs could help, however, they are imperfect since a file owner could remove the ACE that allows the web service's user ID to change ownership. Frank, thanks for your response. On the CAPs, I figured as much, but wondered if there was a way to assign the capability on the server—but I believe it’s only process-based, so I’d have to assign it to nfsd. However nfsd runs as root and so already has the capability. So in essence it seems NFS is the gatekeeper here, a thought which appears to be borne out by the traffic I’m seeing via `nfstrace`—NFS server returns a permissions error to the client. So I wonder how to make the NFS server be okay with that user changing the ownership of files? You are right about the file owners being able to remove the ACE however in this particular context the users would not have this ability via the web service, and when mounting the filesystem themselves would probably not have access to the commands, or know how to use them, or want to; and in any case would be warned against doing so. Drew.-- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
