Re: Why can't root check in files?

[luke]

On 10 Oct, Mike Castle wrote:
>  On Thu, Oct 11, 2001 at 03:37:47PM +1000, address@hidden wrote:
> > However, I still think that I'm onto something good here - the cvs
> > control of Unix config files.  Unfortunately, this sensible cvs feature
> > utterly prevents me from providing this useful facility.
>  
>  Use something like GNU's cfengine
>  (http://www.gnu.org/software/cfengine/cfengine.html) and put those
>  configuration files under CVS control.

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?

Using my script it takes 10 mins to put your system under CVS control.
The learning curve in the simplest case is:

        $ su
        # cvs-etc

If you already use cvs, then there is nothing else to learn.

>  Check the CVS archives.  Been discussed here several times in the past.  :->

I'd like to do that, but it looks like a project in itself.  They're
split up by month, so I have to check through 38 files by thread and
taking a guess at the subject line.  Like I said, a project in itself.

Greg A. Woods replied to:

> > However, I still think that I'm onto something good here - the cvs
> > control of Unix config files.  Unfortunately, this sensible cvs feature
> > utterly prevents me from providing this useful facility.
> 
> 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.

So, since they are in their final resting place, nothing else is needed.

And from this point on, I can happily run cvs diff and see what has
changed since last time, and then on a case by case basis make a
decision about each file before I commit them.  Except that I can't,
because of this restriction in CVS.

I also store the metadata so that *if I need to*, I can checkout the
archive (as long as I'm root, so that I have permission), and run the
metadata files which restores the metadata.

I can't imagine why that would be required, really, since you have
system backups anyway, and you wouldn't try to copy one system's config
files on top of another.

> 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.  The current scheme makes it the path
of least resistance, but that's all.  Here are some sample scenarios
that show yhow the current scheme only promotes accountabiility, rather
than guaranteeing it:

1) I walk up to someone else's machine and make changes and check them
   in.
2) I'm doing (1) with the full co-operation and agreement of the other
   person.
3) It's a login (the extreme example would be a "guest" account), which
   several people are using to collaborate.
4) I have su-ed from my identity to another.
5) I've written a setuid program that runs cvs operations so that they
   can pretend to be me.
6) I have write permission on the cvs file, hence the archive file, so I
   vi the files and change the data in the ,v file.

There are probably other ways too.  In all these cases (except 6), the
ability to say "I'm someone else" is useful.

If you really hate this idea, then record the user as
"real-user"/"claimed-user" in the case where they use the hypothetical
"commit -u USER" that I've suggested.

> This is how accountability is maintained.

No, that's how accountability is maintained if no one does anything
unusual.  Think of it this way: the data you are storing could not be
used in a court of law, could it?

Anyway, I'll go and check the archives and see if I can make more sense
of this, when I have a few hours spare.

Thanks for your comments,

luke