<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
On 11/11/11 7:37 PM, Ian Levesque wrote:
<blockquote class=" cite"
id="mid_82D0D9E3-652A-48D9-BECB-FF06AEC7AD6C_crystal_harvard_edu"
cite="mid:82D0D9E3-652A-48D9-BECB-FF06AEC7AD6C@crystal.harvard.edu"
type="cite">
<blockquote class=" cite" id="Cite_7" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://xkyle.com/solving-the-nfs-16-group-limit-problem/">https://xkyle.com/solving-the-nfs-16-group-limit-problem/</a>
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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks!<br>
<br>
Ian<br>
</body>
</html>