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 email@example.com.
At 00:29 19-12-04, Tony Hoyle wrote: >>Would it be hard to add an [no]visible right or something, which would >>prevent uses from even just seeing a file or dir? So that if they >>checkout or update the repository, they won't even notice the existence >>of the files or dirs on which they have no view access. > >It wouldn't really work... a 'cvs add' would give the existence of the >file away (can't get around this really), as would a lot of other commands >potentially (pretending a file didn't exist would be a fairly big change >and I might not get all the cases for a while). Well as for the 'cvs add', the outsiders I have in mind wouldn't have add access (nocreate) to the dir above it :) But you're right, other commands might offer other ways to reveal the existence anyway. >>This would be very handy when for example different outsiders need to >>known only about the part of the repository containing stuff they're >>related to (i.e. projects/clientname/*.*) > >If the permissions are set up they'll only know about the top level >directory anyway, which isn't much problem. > >If you really need that level of separation separate repositories is >probably a better solution. Hmm yes, indeed it's not dramatic just knowing the dirs exist. And in the unlikely case it is, I could put any 'sensitive' dir names inside dirs with names that don't reveal anything useful. Using separate repositories is kinda uncomfortable, as for example I have a library A which is required for projects B and C, so people with access to either B or C should also be able to read A. This can be solved by separating even further, putting every lib and project in its own repository, but then people have to update *lots* of repositories just to get all the latest stuff they need. With proper ACLs I assumed everybody can just update one big repository and they'd get what I want them to get. >>Another question about ACLs: are they supposed to be set at the server or >>by clients? (just wondering cause I have some trouble getting ACL to work >>properly :) > >Either. Hmm ok, cause I recently got errors when trying to do it on the server... Doing 'cvs chacl' as a client seemed to work better (that is: no errors), but still didn't cause the access restrictions I intented. I mailed about this a few days ago, I'll copy/paste it again below. Sorry for posting it here twice - I hate to be pushy, but somehow I just can't get this to work and I'm hoping you or anyone else might have some advice... cheers! Rogier // [copy of previous email] >Hi everybody, > >I'm trying to limit the access to certain files for some users, but didn't >succeed so far. > >First I tried on the following on the server (in some dir within the >repository): cvs chacl -u john -a nowrite bla.h >Hoping this would allow john to checkout/update "bla.h" but not commit it. > >(first got an error about CVSROOT not being set - I never did any cvs >things on the server yet, only created a repository there using the gui >and used TortoiseCvs on client machines...) >Then it said: > >>cvs chacl: in directory .: >>cvs [chacl aborted]: CVS directory without administration files >>present. Cannot continue until this directory is deleted or renamed. > >When I tried "cvs lsacl", same thing. Is changing ACL stuff not supposed >to happen on the server? > >I also tried on a client PC (where I use the cvs account "rogier"), and it >seemed to work now, when doing "cvs lsacl" afterwards I get this: > >>Directory: . >>Owner: peter >> >><default> >> read >> write >> create >> tag >>File: bla.h >> >>user=john >> write(deny) > >However... john can still commit changes to bla.h :( > >Since all cvs users in our repository map to the same single Windows guest >account on the server ("CvsDummyUser"), I though maybe the rights refer to >real windows users rather than the 'virtual' cvs users in the passwd >file.. so I did the same chacl command with CvsDummyUser instead of >"john", but still no difference. > >On the server, the cvs\fileattr.xml file looked ok though (see also lsacl >result above which seemed all right) > >Two questions: > >- What am I doing wrong? :) >- Isn't it scary that clients can change the ACL rights, i.e. what >prevents a user from increasing his own rights to certain files? > >Thanks a lot, >Rogier