> Yeah, as others have said, the protocol just gives the client no way to > say "this rpc call is being made by a process that has the CAP_CHOWN > capability". All the server gets is a uid and some gids (or a krb5 > principal). That answers that, then. Thank you (and Frank earlier) for clarifying that for me. > I guess in theory we could provide some way to tell the server that a > certain user to get CAP_CHOWN. Doesn't that it mean it could > effectively access anything by chowning it to its own uid and the > chowning it back? Maybe we'd want some more restrictive capability. Or > maybe you'd be OK with just mapping the user to root. In this context, and I don’t see a lot of use cases for this, the web service’s user can do whatever it wants, and basically acts like root. On my list of things to try for this case is to map the user to root on the server, so that effectively that ID can do whatever it wants. I don’t know if this will work and I don’t believe it’s a good solution for a couple of different reasons (for example, it would apply to other filesystems exported by the fileserver). > Huh. Chown as root on 4.1 works for me on latest upstream. Hard to > think why 4.1 would make a difference. If I find anything interesting there I will let you know but I believe it to be a red herring. Actually, I just rebuilt the exported filesystem and I’m now able to do this with 4.1, so perhaps it has to do with the stuff I was playing around with for ACLs. >> In looking into ACLs to see if they may provide the answer, I came across the NFSv4 ACE permission of `o` for ownership. This seemed to me to be exactly what I needed. Unfortunately, while this permission appears to be accepted, it is not applied and has no effect: subsequent calls to `nfs4_getfacl` show no change, and ownership changes are still disallowed. I have tried enabling ACLs and user extended attributes on the exported filesystem, but they appear to have no effect. >> >> I understand that NFSv4 ACLs are not fully supported in Linux due to the inoperability with POSIX ACLs, however, a Linux-NFS wiki page on ACLs (http://wiki.linux-nfs.org/wiki/index.php/ACLs) describing the existing mapping of NFSv4 ACLs to POSIX ACLs states that while the mapping is imperfect, “it accepts most NFSv4 ACLs” and states the only exceptions have to do with explicit denies. The remaining question for me then is around the NFSv4 ACL and the ownership change permission, and whether I should be able to get that to work, especially on a stock system. I know there are some issues with mapping NFSv4 ACLs to so-called “POSIX” ACLs, but I didn’t see anything in the documentation to suggest it isn’t implemented. Should I expect this to work without installing the richacls software? Here’s an example of me trying the NFSv4 ACLs for this: [testdir1] nfs4_getfacl drewsfile A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:rtcy [testdir1] nfs4_setfacl -a A::OWNER@:o drewsfile [testdir1] nfs4_getfacl drewsfile A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:rtcy So it is accepted, but fails to apply. Here’s trying to assign a garbage permission: [testdir1] nfs4_setfacl -a A::OWNER@:p drewsfile Bad Ace Mask:p Failed while inserting ACE(s) (at index 1). Is this because of the mapping to POSIX ACLs, which has no provision for ownership management by non-root users? Does this require the richacls software? Thanks, 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
