Hi Ian - > I'm in a situation where I need on-disk user data to be accessible by a > webserver process but also by the owners when they ssh into the system. My > initial ambitious plan for this was to have a "mirror" group for every user > that contained the user and also the web server daemon user. With careful > management of who created data and where it was created this looked like it > was going to work -- the webserver would assert access control policies so > the data could only be accessed by the owning user when coming in through > the web interface, and the user when ssh'ed in to the system could see all > their data but not that of other users. NFSv3 and its 12 (or 16?) group > membership limit meant this didn't get me very far in the end.
This is generally the way admins solve the problem: put the apache user in shared groups that thereby grant permissions to write to various directories which are group-owned by the shared group. The SGID bit set ensures that all files/dirs created within are manageable by both users in the group. That said, I googled and found this informative blog entry: https://xkyle.com/solving-the-nfs-16-group-limit-problem/ The author basically concluded that the 16 group limit on RPC calls is a native limitation of auth_sys, not NFS itself. You can tell rpc.mountd to not try to do auth, and allow the underlying NFS server to do the lookups. This is possible by passing the --manage-gids option to rpc.mountd. HTH, ~irl _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
