URL:
<http://gna.org/task/?func=detailitem&item_id=2219>
Summary: users that are in more groups than the system
allows it
Project: Savane
Submitted by: yeupou
Submitted on: dim 11.09.2005 à 09:50
Should Start On: dim 11.09.2005 à 00:00
Should be Finished on: dim 11.09.2005 à 00:00
Category: Backend
Priority: 1 - Later
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Planned Release:
_______________________________________________________
Details:
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?
_______________________________________________________
Reply to this item at:
<http://gna.org/task/?func=detailitem&item_id=2219>
_______________________________________________
Message posté via/par Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
Savane-dev@gna.org
https://mail.gna.org/listinfo/savane-dev
