[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 ;-)?
>> 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.
You still haven't addressed the issue of "mkdir -p dir1/dir2; cd dir1; touch
dir2/file; cvs add dir2; cvs rm dir2/file". Your proposal mentions nothing of
"cvs rm" going up directories trimming off CVS admin subdirectories off empty
hierarchies. 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).
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.
>> 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.
But it doesn't say that this is the only way. Again, it mentions nothing of
ACLs. We've outlined a way where CVS can coexist peacefully with ACLs but you
want to break 'cos of some fanatical beliefs you have.
>> 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....
Again, those other solutions require too much overhead.
>> 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.
If your so headstrong with this part of your proposal, I guess I'll have to
simplify your "fix" in my copy of CVS. I'll also be sure to share my
simplification with the community.
>> >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!
Yeah, you're right, I meant Big Brother tactics.
>> 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"?
What, you mean a root script running in the background chowning directories?
I've already said we can't rely on sysadmin-dependent stuff 'cos they may not be
reachable if something should go wrong.
>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:
1. Groups with commit priveleges require read and write permissions to the
directories.
2. Groups with checkout priveleges require read permissions to the directories
and files.
3. Only the owner of a file/directory can change the permission of that
file/directory.
4. Files/directories within the repo are owned by the last person the
commit/create the file/directory.
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.
Noel
