Re: Why can't root check in files?

[Greg A. Woods]

[ On Monday, October 15, 2001 at 09:50:29 (+1000), address@hidden wrote: ]
> Subject: Re: Why can't root check in files?
>
> 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.

Trust me -- I have a _LOT_ of experience in this very matter.

I've managed system configuration parameters with CVS for years now.

(I don't do so at the moment though because CVS would be over-kill for
the systems I currently manage.  These days I just use SCCS or RCS
directly on the files, with SCCS or RCS sub-directories in their
immediate locations.)

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

Maybe.

However there are many variables here.  For the _general_ case it is
insufficient to make such an assumption.  For the _general_ case commits
to CVS must always be done as a unique individual identifiable (i.e.
authenticated) and authorised user.

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

Oh come on now!  This issue has been discussed to death a hundred times
or more in this forum!

It's trivial -- you record them by checking in the scripts and/or
control files that make up your "build" system.  (eg. your makefile)

This is yet another reason why you _need_ an intermediate "build" step
to install the source files into their target locations.  It is this
very process which records your metadata.

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

Oh, no!  Absolutely NOT!  My method mandates that _all_ changes be made
through the CVS source files, and _only_ through the CVS source files.

This is yet another reason why you _need_ an intermediate "build" step.

You _want_ all changes to be forced through the change control system!

While "loss" of unauthorised changes is a risk with my system (though it
can be mitigated in various ways by adding more checks), it's also a
very successful (and proven so) way to enforce discipline on one's
fellow administrators!  :-)

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

It's not exactly a checkout of those files -- it's a checkout of the
_sources_ for those files.  There's an almost inifite conceptual
difference that's critical to understand here!

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

My scheme works both locally or for any number of target systems!

This is yet another reason why you _want_ an intermediate "build" step!

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

Yes, but that's irrelevant.  In my multi-system implementations there's
one master administrative system that may be accessed only by authorised
administrators.  The changes made on that one machine are propogated
through trusted mechanisms to the client machines in the cluster.

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

No, I solved the exact same problem you're attempting to sove, just in a
far more general, usefule, and safe, way.

-- 
                                                        Greg A. Woods

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