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

[Larry Jones]

Patton, Matthew E., CTR, OSD-PA&E writes [quoting me]:
>
> > You're foolish; you should never run CVS as root.
> 
> er, why not? In client-mode? Right now I'm not using it under sudo but that
> is the end goal so that only "cvs up" is allowed to be run as root by an
> otherwise non-privileged uid. Are you telling me CVS is so bug-ridden that
> it's untrustworthy? That despite the legions of problems, practically the
> entire opensource movement uses it? and often in pserver mode (which runs as
> root I might add - not that it necessarily needs to most of the time but
> nobody has written any examples I've seen that didn't have it running as
> root) no less? Come on now...

Pserver runs as root just long enough to authenticate the client user;  
as soon as the user has been authenticated, it drops root and runs as
that user instead.  CVS is not "so bug-ridden that it's untrustworthy",
it was never *designed* to be trustworthy, and so should not be trusted.
You should never run *anything* as root unless you absolutely have to,
and I would certainly think twice (or thrice, even) about running
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.

> > CVS is a revision
> > control system, it is *not* a complete file system manager.  
> 
> huh? A file system is nothing but a collection of files in a hierarchy.

And a whole bunch of metadata like file type, ownership, permissions,
link counts, flags, modification times, etc.  CVS makes some attempt to
manage the few bits of that metadata that make sense for working copies
of files, but (currently) makes no attempt to manage all of it (although
the notoriously buggy PRESERVE_PERMISSIONS code did make an attempt to
manage most of it).

> active set is nothing more than a checkout of the repository that is never
> edited in-place. How does this diverge in any way from CVS' design and
> normal use?

Normal use is to check out an individual *working* directory, not a
production directory that requires specific ownership and permissions.

> In keeping with the unix tradition of 1:1=task:binary lets strip out every
> last chown/chmod out of the CVS codebase as it relates to checkin/out of
> user files (house-keeping stuff I can't comment on just yet) and deep-six
> the PRESERVE_PERMISSIONS code since it really is none of CVS' business;
> past, present or future. fopen(2) is all we need, right? So in addition to
> my patch it looks like we might need to yank the odd line from checkin.c.
> client.c has this change_mode() which is called once in client.c and
> server.c that looks suspicious and probably a few others that seek to modify
> permissions.

Now you're just being silly.  The notoriously buggy PRESERVE_PERMISSIONS
code is already deep-sixed; it's been completely disabled for a very
long time.  There are no chown() calls in CVS outside of that code.

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.  It also allows you to ask for checked-out files to be
read-only.  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.  It also makes a feeble attempt to track read/write permission to
provide a modicum of privacy from prying eyes.  But it makes no attempt
to track all of the metadata, nor should it.

-Larry Jones

I always send Grandma a thank-you note right away.  ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin