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. > 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. > > 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. _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
