On Tue, 2005-08-23 at 00:39 +0200, Sylvain Beucler wrote: > > The problem is that the number of groups for a given processus is a > fixed structure. This means a Unix user, and hence a Savane user > cannot be part of more than a given number of groups. > > The first solution at Savannah back in 2003 was to recompile the Linux > kernel with more important number of groups per process.
It was a little more bothersome (recompiling shadow, ssh) : http://savannah.gnu.org/savannah.html#NGROUPS_MAX > A third solution would be to stop using groups and switch to ACLs. I'm > not sure about the limits of ACLs though. Mainly those of the filesystem, something like XFS has unlimited ACL entries I believe. On the other hand, you'll run on a terrible scalability issue : if a group definition changes, you will have to update all files where this group has some form of authorization (repositories, download, etc). I'm not an ACL expert, but it seems a rather bad idea. > A drawback of ACLs is that when a user quits a project, the whole > projects need to be setfacl'd to remove the user from all the > ACLs. However, you'll note that the group model does not fix this > issue either: if a user is owner of a CVS directory, for example, he > still can commit in it even if he's not part of the group anymore. So > apparently chown/setfacl when a user leaves if a necessary constraint. True. CVS could be patched for this, most of the time it is desirable that the owner of a file be made irrelevant, it could be forced to 'nobody'. > I would love to hear about a fourth solution :) > > > Any comments? What about some ACLs-enabled backend? Does Gna! has to > bother about this issue or not yet? Fortunately, no. We're rather interested in distributions evolution, since we seek for the lowest maintenance effort. I wonder what is NGROUPS_MAX in Linux and Debian Sarge, and which packages are properly updated.
