[ On Thursday, February 24, 2000 at 20:50:24 (-0500), Noel L Yap wrote: ]
> Subject: Re: removing the need for "cvs add file" to contact the server....
>
> [EMAIL PROTECTED] on 2000.02.24 17:17:25
> >[ On Thursday, February 24, 2000 at 13:34:36 (-0500), Noel L Yap wrote: ]
> >> The manual doesn't mention ACL's
> >> at all.
> >
> >Hmm.... I wonder what that could mean!
>
> Are you implying that noone should use ACLs within the repository? I thought
> CVS and permissions were orthogonal (except where they intersect ;-)?
It means using CVS with filesystem ACLs in the repository may lead to
undefined behaviour. I.e. you're on your own.
> >> 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....
>
> It means no such thing. So long as there's a process that allows both to be
> used, there's no problem using them. We've already outlined such a process.
> You now claim that that process is dependent on a bug. I claim that "cvs add"
> and "cvs ci" support for empty hierarchies isn't a bug.
Ah, sorry, "BZZZZZT", but you're wrong. Several people have shown this
several times already.
> You still haven't addressed the issue of "mkdir -p dir1/dir2; cd dir1; touch
> dir2/file; cvs add dir2; cvs rm dir2/file".
I have. You haven't paid attention, possibly because you didn't like
the answer.
> Your proposal mentions nothing of
> "cvs rm" going up directories trimming off CVS admin subdirectories off empty
> hierarchies.
That's clearly outside of my proposal.
However in case you haven't tried it in real life yet, I will point out
that the handling of this case is already well defined by "cvs update -P"
> Such a scheme would have to test each ancestor directory until it
> found one that's not empty (which may mean that at least one of their
> subdirectories isn't empty).
I proposed no such scheme.
> You also claim that no CVS commands treat directories specially. I've already
> said that "cvs watch dir" treats dir specially. There's no reason why "cvs add
> dir" (when dir is an empty hierarchy) is dangerous in that it'll lead others to
> believe directories are versioned.
It does not. It simply operates on all the files in the directory,
current or future. I've explained this at least twice now.
> >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....
>
> Again, those other solutions require too much overhead.
Then follow my initial suggestion and simplify your requirements. A
proper risk assesment is almost guaranteed to do this for you.
> >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.....
>
> I've defined the rules:
Those are not the kinds of rules I was talking about. Define the
security policy. You'll have to do a risk assesment first though if you
expect to be able to do a sensible job of that.
> Therefore: In order to maintain and manage the permissions within the repo, at
> least all directories must be owned by the cvs admin. The simplest way to
> achieve this is to have only the cvs admin create directories within the repo.
Your conclusion is wrong.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
