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.
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