Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: > If someone can write to group then they can potentially access any part > of the repository, just adding the names of the users they want to > impersonate on their group list (each 'user' is a group too). Provided access to CVSROOT is properly locked down, being able to put group (and admin) under version control and manage them from a sandbox seems like a feature. If you are going down this route (making CVSNT secure against attackers who have commit access to CVSROOT), don't you need to prevent things like commitinfo and historyinfo (and any filters they might call) going into checkoutlist? An attacker could write a historyinfo filter that silently tries to add them to the admin file. Maybe an alternative would be to prevent checkoutlist itself going into checkoutlist, and allow anything else. Along with some helpful warning comments in checkoutlist, that should ensure that risky files can only be added to checkoutlist by someone with direct repositoty access, who is aware of the consequences. > If you set an ACL so that nobody but administrators can even checkout > CVSROOT then it'll still work and be safe - the server itself accesses > the files directly so doesn't need read access via that mechanism. Are history and val-tags still exceptions to this (http://www.cvsnt.org/wiki/SetAcl)? Or are you suggesting a CVSNT ACL rather than an NTFS ACL here? Aidan