[ On Thursday, February 24, 2000 at 13:34:36 (-0500), Noel L Yap wrote: ]
> Subject: Re: removing the need for "cvs add file" to contact the server....
>
> Greg, we've gone through this several times.
More than that, I'm sure.
> The manual doesn't mention ACL's
> at all.
Hmm.... I wonder what that could mean!
> Does this mean that they shouldn't be used? Should I also not use
> emacs 'cos the manual doesn't mention it?
No, of course not -- it may mean that you can't use them with CVS
though, at least not without some additional support tools....
> CVS doesn't manage permissions. This is fine. What's not fine is that you say
> that it prohibits me from managing those permissions.
No, I did not say that.
What I did say, and what the manual documents, is that there is one way
in which CVS works well with filesystem access controls and you'll have
the least amount of headache if you figure out how to map your needs
into that implementation.
> Perhaps the problem is that you've never used (nor have ever needed or wanted to
> use) ACL's. On top of that, you have this mindset that your environment
> reflects everyone else's environment.
Well, given that I described a way that you could use still manage to
use ACLs with CVS it would seem you're spouting nonsense here....
> Nowhere have I ever said that CVS must be changed to meet my needs. It works
> now (although you claim that this is a bug). Even if "cvs add dir" was replaced
> by "cvs add dir; cvs ci dir", the procedure I've outlined will still work so
> long as dir is added into the repo whether or not it's hierarchy is empty.
Sorry, but that's just not going to be possible with my fix to "cvs
add". You'll still have to learn to use CVS as it is intended to be
used and/or adapt your management tools to work in a different way.
> >A repository maintenance program run as a
> >privileged user is only one of those alternatives. A proper risk
> >assessment and perhaps better definition of your access control
> >requirements might also simplify things to the point where excessively
> >paranoid schemes are not necessary and the documented scheme will be
> >more than adequate.
>
> We've gone over this, too. Such SS tactics won't work in our environment.
Who said anything about "SS tactics"!?!?!? You're way off your rocker
again Noel!
> Furthermore, these solutions don't solve the original problem of *managing*
> permissions within the repo.
Huh? What don't you understand about "automated maintenance tool"?
If you can define the rules then they can be automated. Obviously such
maintenance of access controls requires privileges that span all of the
rights being assigned, whether the task is automated or not.....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
