Re: Why can't root check in files?

[Greg A. Woods]

[ On Friday, October 12, 2001 at 10:51:23 (+1000), address@hidden wrote: ]
> Subject: Re: Why can't root check in files?
>
> I've looked at it.  It is solving a somewhat different problem.  It is
> not only far heavier tool than what I need, it's also more active (li
> kely to reset permissions to what you had laboriously constructed), and
> has a much larger learning curve.
> 
> Hands up how many people are using cfengine on their home system?

That's not quite a fair question.

The issue isn't which tool you use to drive the configuration of your
system using the source files that you will manage with CVS, but rather
that you start out with the premise that you do indeed need such a tool
in the first place.  The choice of which tool you end up using will be
guided by requirements entirely unrelated to which change tracking tool
you use with the input source files.

> Greg A. Woods replied to:
> > 
> > You need to use some intermediate build process, which when necessary
> > must be run as the superuser, to install your config files into their
> > final resting place.
> 
> That's not actually true.  I *have* a script that runs over a set of
> /etc-like directories and adds all the plain text files into a CVS
> archive, and populates the live area with CVS directories and
> .cvsignore files without altering any of the existing files.

Yes, it is true.  Your script is part of that tool, though it's
incomplete and apparently headed in the wrong direction.

You most definitely do not ever want to make /etc a CVS working
directory!  That's not only dangerous, but is why you're ecountering
this problem in the first place.

You now need a corresponding program to install the resulting source
files into their proper locations in the production system.

> > However the maintenance of the source files and commits of their changes
> > to CVS must be done by a real user-id, i.e. some user-id that represents
> > exactly one real-world person.
> 
> You can't guarantee this, ever.

Excuse me?  Accountability is a fundamental cornerstone of all computer
systems security.  You have no real security without it.

Everything you said after that sentence is further down the road of your
confusion and isn't worth arguing point by point.

The process I've used successfully in the past was to build a mechanism
much like cfengine (but more primitive), and to create a CVS module
writable only by the "wheel" group.  This module was populated with
configuration files for the target system(s).  Users then checked out
this module, as themselves into a private and protected working
directly, and from there they could commit changes to the files in it.
To install the resulting files into production they would 'su' and then
run "make install" in their working directories.  One of the first
commands run by the makefile was a "cvs -nq update" check to ensure that
the files they were installing were all committed (and up-to-date).
Other simple consistency checks were also done on some of the files,
such as ensuring the old copy was still identical to the revision noted
in its RCS $Id line (i.e. to ensure no uncommitted changes would be
clobbered).

Accountability here is maintained in several ways, including through the
CVS repository and through the 'su' logs.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>