RE: cvs commit/up's change file ownership in working dir.

[Patton, Matthew E., CTR, OSD-PA&E]

Classification: UNCLASSIFIED

address@hidden wrote:
> anything as complex as CVS.  Without too much effort, anyone 
> with access
> to the repository can plant commands that you'll end up 
> running as root
> without even knowing it.

can you elaborate on this? what magic files is the cvs server going to be
looking for? Are we talking about cvs running the various support scripts
(loginfo, commitinfo etc)? That I understand. I guess it wasn't clear, the
CVS *server* is NOT running as root. only the client is. What kind of tricks
is the client up to then?

> Some mucking about with permissions makes sense in the environment CVS
> was intended for.  For example, CVS makes the RCS files in the
> repository read-only (just like RCS does) to prevent people 
> from mucking about with them.

these kind of games don't make sense to me. the parent directory in the
repository is frequently if not almost always group-write (because of CVS
artificial design limit). Taking the 'w' bit off a file isn't going to stop
anything. And if the repository is remote, the tactic is even more of
questionable value is it not? But by implementing this you've artificially
limited the cvs admin's options by a considerable amount.

eg. if the parent dir is g=RX then by tagging individual files with g=RW I
can support 2 distinct classes of persons within the same group definition
with the potential to add another: those that are members of the group and
can read all files, and those that can edit certain and possibly all files.
If the gid of the parent dir is different than the files contained within, I
have another group that can add files to the collection to boot. This really
isn't an unreasonable or overly complex setup. If one's needs are trivial
then you don't care if you have this or not.

> It also allows you to ask for checked-out 
> files to be read-only.

that's fine. Does not need chmod to do that but rather the proper flag to
fopen() which we do for the most part I think.

>  It makes a feeble attempt to track execute 
> permission since
> it's convenient to be able to execute a script that you've 
> just checked
> out.

Feeble indeed. if umask&CVSUMASK=027 for example, a script that was
originally 555 or 755 is now 530 or 730. oops!! It's still executable by the
user, but what what happens when I check that file back in? And wasn't this
supposed to be a build matter? I will grant you that it is nominally
user-friendly not to have to make the script executable before being able to
use it, but the correct way is to support 'mode' as an attribute of the file
to be set just like commit messages are and NOT simplistically grabbing them
off the working file which was where the whole mess started.

> It also makes a feeble attempt to track read/write permission to
> provide a modicum of privacy from prying eyes.

It's the comingling of repository permissions with those of the working dir
which is the fundamental fallacy here. Visibility within the working dir is
the user's umask&CVSUMASK's problem and his savvy with respect to his work
space and the nature of the files. The repository content's visibility and
control over checkout/in is the CVS admin's job and responsibility and is
100% independent of the developer. The developer should not have to resort
to a script to pound the checked out contents into a suitable form when 3
simple fields can take care of 90% of the problem regardless of what the cvs
admin might be doing/have done to the repository to suit his requirements.
Yes the two entities cooperate but the programmers really have no business
dictating preconditions to the admin (oh, please treat 'x' as special, or
don't set CVSUMASK to such and such, etc). The admin needs to know who
should have access and to what and if he wants to be tightfisted about
permissions and cross-project visibility that's his call. How the content
shows up in the working dir is the developer's problem. Therefore the
developer has only two paths available to him: tagging the file with some
fields, or writing a script to munge things.

CVS wasn't designed with security in mind as has been said. Well then CVS
has no business interjecting itself where it don't belong and especially
making feeble attempts at it and pretending to do something. Do it right, or
don't do it at all.

Don't get me wrong, I like CVS a lot. I'm just heavily annoyed at
inconsistent behavior and don't like band-aids or hacks which are worse than
the disease when design can obviate them.