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