https://mail.gna.org/public/savane-dev/2005-08/msg00043.html

\"I would love to hear about a fourth solution :)\"

For the record:

- solution 1: recompile the kernel -- painy, hard to maintain (recompiling the kernel on each upgrade greatly enhance the risk of having admins not upgrading kernels, and we know the price of that)
- solution 2: using a proxy mecanism -- probably not working for half of the service one would like to provide
- solution 3: using ACL -- some says it\'s not yet working properly, some others says it would not completely resolve the issue. I dont know personally, I never used ACL (or only for a demo). I assume this is not the solution we want.

I have a fourth solution. I just came out of my mind a long time ago. It may not be very practical but:

we could have sv_groups checking the NGROUPS_MAX in /usr/include/linux/limits.h and decide, if for a user it counts something bigger than that, to create a new user, like user1 (or whatever), add this new user to the new groups it should belongs to. That would be transparent on the frontend.
- Apart that we would have to restrict new account names accordingly (not allowing someone to create ada1 if there\'s already ada1.. etc).
- The user would have to be told to use ada1 for ssh connection with X group, not ada. It may be a real pain in the ass.
But that would be working.

But recent Debian news brought me hints about 1st solution: now security is provided for Debian Testing: people just have to use Testing kernel if they are in this particular case -- using testing on a production server may not be very nice, but I think it is possible with apt-get to only using testing for a defined set of packages.
Well, it sounds like solution 1 but it\'s not exactly.
It not uberconvenient, as at some point, you may have a kernel depending on modutils or stuff like that as shipped in Testing. But anyway, it\'s a matter of time and I bet there are not so many servers in this case.

All in all, the probably cleanest solution is still to use ACL, that would work in all case -- but probably the one that would cost the more in development time. My 4th solution is clearly a cheap and dirty workaround.

And intermediate solution would be to implement a restriction on members right: write access on repositories or not, by default set to not.
(not per repository kind, that would be complicated and would somehow restrict usage of the software -- for instance, it would not be helpful with Gna setup). It would means that only users really needing such account would get one. And I guess in plenty of cases, there are members that in fact does not require the write access.
That would not fix the issue, but that would make it less probably.

BTW, I think we\'re near, at Gna, to have someone in more than 32 groups.
I dont know what solution we\'ll pick. It may well be the repackaging possibility. If it\'s just a matter of updating limit.h, should not be a problem to have well maintained packages, and easier than dealing with testing kernel.
But in the past, useradd had also to be patched. Is it still the case?