David R. Chase writes: > > Basically, I'm wondering if there's any way to limit read/write access to a > repository on a modular level, that is, some users mapped in > $CVSROOT/CVSROOT/passwd will have read or write access to some modules, > while other users will have it for others. I'm mainly trying to obtain > finer granularity access control via pserver (or other remote access) > authentication rather than via the filesystem's uid/gid and related > permissions. With a fairly large repository, administration of large > groups of users for a large number of modules can become a nightmare if > done on the filesystem level without ACLs. I'd rather have one system user > that a great number of developers are mapped to as virtual users, rather > than creating a new user or group for each project's members to access the > repository with.
I strongly suggest using the filesystem's uid/gid and related permissions. Assign a group for each set of modules that require the same access permissions, assign a unique uid to each user (for traceability), and assign each user to as many groups as necessary. > If not, and I wanted to write a patch to add this feature, what would be > the best way to do it? Have module-permissions defined in $CVSROOT/CVSROOT/ > [readers,writers] or have permissions defineable in each module directory > such as $CVSROOT/module-name/config-dir/[readers,writers] ? (personally, I > believe the second choice reduces overhead as the lookups could be done on > modular files rather than the global readers/writers files which could tend > to become very large). This is a very bad idea -- CVS is a version control system, not a security system. Using it to implement security is a sure route to exploitable vulnerabilities (witness pserver). -Larry Jones I hope Mom and Dad didn't rent out my room. -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs