Re: Why can't root check in files?

[luke]

On 11 Oct, Greg A. Woods wrote:
>  [ 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.

Agreed, as long as the change tracking system meets minimum
requirements.  cvs meets them easily.

> > 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.

The problem I encountered in the first place was tools like webmin or
linuxconf or installation of packages making changes with unexpected
side-effects, that I had no way of tracking; and to a lesser extent, I
would occasionally make a change that seemed okay at the time, but
which I discovered months later had effects beyond what I wanted.

My system is now under cvs control via having /etc as a cvs working
directory, and so far at least it has caused me no problems, and worked
just as I expected.

I have no idea why you claim it is dangerous.

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

In your scheme, yes.  In my scheme, no.

> > > 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.

Agreed.  I think you're misinterpreting my remark.  My list of 6 ways
of subverting the accountability that you provide via the existing
mechanisms demonstrates that the methods are not rigorous.  They're
very practical, however, and we've all been using them quite happily
for many years.  I think they're good enough.

I just got the impression from what you'd written, that you thought
the information recorded was provably always true.

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

Sorry - I obviously don't `get' your objection.  I'm starting to feel
that we're talking at cross-purposes.  If you feel like explaining my
confusion, I'm certainly prepared to listen.

>  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.

Yes, the su logs will probably be enough to provide proper
accountability in this case.

I also don't see how you recorded changes like changes to the metadata
information (file permissions, owner, group, setuid-ness, etc.), or how
you propagated those changes to the /etc area.

I record that information in metadata files, so that they can be
compared later (with some effort).

Also, your method would also require a diff of each file to be
installed, against the corresponding live file - since other people in
the wheel group could make changes directly; possibly via webmin or
linuxconf or any of the other sysadmin tools floating around, or by
installing new packages.  Otherwise you risk wiping out changes
(possibly good changes that may have required lots of work).

I don't see any benefit from having a cvs checkout of the etc files
somewhere else - the system isn't going to look at any of them if
they're not in /etc, so I can't see much value in it.

Maybe the clue is in your mention of "target system(s)".  Perhaps you
were pushing out the changes to multiple machines.  My scheme is
designed to work locally, just on the local machine.  One of the
reasons for that is the great security risk you run if you allow root
permissions to be shared between machines - I mean, if being root on
one machine gives you root privileges on another.

I expect you didn't mean that your changes were propagated that way; I
expect if you had to push them out to remote machines you transferred
the files to a temp directory and then used ssh or the like on the
remote machine to become root there explicitly, and then installed the
files.

Anyway, my guess is that you were trying to solve a different problem
to me.

BTW, I used my script to put another home linux machine under cvs
control - a RH 6.2 system this time.  It worked smoothly, took about 10
minutes, and is also working exactly as expected.

luke