On 11/11/11 7:37 PM, Ian Levesque wrote:
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.
That is a great post, and I'll forward it to Peter who I'm sure will be
interested. Unfortunately the last paragraph or two describe that even
with rpc.mountd there is a limit of ~150-200 groups. We'd already be
hitting that limit with our current system. I need to at least be able
to support 2000 users, and ideally 10k to 100k. the "apache" user (or
whatever it is called) can't be in the user group fro all of these, nor
can I create a "webshared" group that contains all users and the apache
user.
I think the chmod u+t,g+t approach is currently the most promising,
followed by SELinux ACLs. I'll have to experiment once I have the
dev-portal using the dev FreeIPA system.
Thanks!
Ian
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
