Re: [Savane-dev] Too much groups per user (August 28, 2005 - 16:34)


On Thu, Aug 25, 2005 at 12:27:28PM +0200, Vincent Caron wrote:
> On Wed, 2005-08-24 at 23:44 +0200, Sylvain Beucler wrote:
> > > 
> > >   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'.
> > 
> > It's not about files, but directories :) CVS "changes" files by
> > removing and adding them, not by modifying them.
>   In a CVS repository, files are stored as RCS files and modified in
> place, am I wrong ? And the owner of this file is the latest
> authenticated comitter, as far as I know. We use sticky groups on
> folders, and CVS makes sure newer repository folders inherit the right
> bits (sticky, group write, group ownership). I don't see where user
> ownership is important (for our usage) on the repository side.

Last time I tested, CVS didn't edit in place. Remove then replace. So
directory-driven permissions.

> > I think though that CVS should not be patched when it comes to
> > security. That's unauthorized access. Oppose that to data integrity,
> > eg when authorized users try to change the history of the RCS files -
> > in that case, CVS is the one in charge of enforcing his laws.
>   On Gna! we maintain a patched CVS which implements a smarter
> --allow-root option. We did so because it was simple, and made the whole
> repository access much easier and safer to control. Whenever Debian
> releases an update, our repackaging work is mostly automated (fetches
> source, adds patch, repackage).
>   Patching is not evil if it's the easiest thing to do.

Sorry for not being clear. I said that it's not the role of 'cvs
server' to enforce access from unauthorized users, but the role of the
Unix permissions system.

Maintaining a patch is another story :)

> > >   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.
> > 
> > Well the good news is that Debian testing and unstable use 65536(!) :)
> > - cf. /usr/include/linux/limits.h. I made a successful test with 100
> > groups on my Debian testing box. The bad news is that stable is still
> > sticking to bad old 32 :[ Do you have some other distros under the
> > hand to test?
>   Maybe we could share a Debian repository with a few Sarge packages
> recompiled with proper limits ? This initiative could be useful to other
> people as well.

That's an interesting idea. I can first ask Debian why there is this
error, then see if there's a preferred way to publish fixed packages
(the very best being to publish such fixed packages directly in


You are on the mail server.

Generated by mhonarc, Mon Aug 29 11:00:05 2005