CVS management of /etc - permissions problem

[luke]

I've recently tackled a problem I've wanted to solve with CVS for a long
time now - namely, managing the configuration of a Unix machine
(especially desktop Linux machines), via CVS.

The rationale is that if I change a system config file, and months
later discover that something has stopped working, or if some install
program has written over a config file without my knowledge, then it'd
be great to be able to do a cvs diff and see what has changed.

Should make it really easy to diagnose problems, and considerably ease
the burden of system maintenance.

To this end I've written a script which checks in as much or as little
of /etc's text files as you want.  And now I've found that CVS is
getting in the way, by wiping the group and file and directory
permissions of the files being added.  (It doesn't change the
permissions of the files you add - but the permissions etc. in the
archive seem to owe more to your umask than to the file.  So, for
example, /etc/passwd would be readable by everybody, or /etc/profile
might not be readable by anyone except root.)

I've noticed the discussions about directory permissions, but none of
them would solve this problem.

>     From: Dave Sherohman <address@hidden>
>  Subject: Re: file permissions when adding directories via pserver
>     Date: Wed, 20 Dec 2000 17:30:25 -0600
>       To: Matt Munz <address@hidden>
>       Cc: info-cvs mailing list <address@hidden>
> 
> On Wed, Dec 20, 2000 at 03:13:55PM -0500, Matt Munz wrote:
> >     I am currently having the problem that one user cannot check out a 
> > directory made by another, due to conflicting permissions.  After pouring 
> > over the CVS manual(s) with little success, I thought I'd see if any of you 
> > could help.
> 
> Make the root directory of the CVS repository owned by group 'cvs',
> group-writable, and sgid.  Make all your CVS users members of the cvs group.
> Like so:
> 
> drwxrwsr-x  46 root     cvs          4096 Dec 20 16:19 cvs/
> 
> The important part is that the repository's root directory must be sgid.
> This will cause all files and directories created within it to inherit the
> same groups settings (owned by group cvs, group-writable, and sgid).  Any
> user in the cvs group will then be able to modify files in the repository.

Unfortunately, for this kind of revision control, permissions need to
be determined by the input on a file by file basis, not over-ridden by
a directory-wide setting.

>     From: address@hidden (Larry Jones)
>  Subject: Re: file permissions when adding directories via pserver
>     Date: Thu, 21 Dec 2000 00:32:16 -0500 (EST)
>       To: address@hidden (Matt Munz)
>       Cc: address@hidden
> 
> Matt Munz writes:
> > 
> >     When a user logs in to cvs via pserver and adds a directory, what
> > determines the file permissions of that
> > directory?  What determines the ownership, read, and write settings,
> > etc.?
> 
> The operating system.  On BSD Unix (where CVS grew up), the directory
> would inherit the ownership and permissions of its parent directory.  On
> AT&T Unix, it would be owned by the user that created it and have
> his/her default permissions.  On Linux (and other hybrid systems), you
> get AT&T behavior by default, but can get BSD behavior by setting the
> sgid bit on the parent directory.

Quite right, though it certainly doesn't have to work that way.  E.g.
tar and cp can be used so as to preserve permissions, owner, and group.
(Possibly only if done as root, but for system config files, it's root
that is the only possible user to be doing the full /etc revision
controlling.  Quite rightly.)

>     From: Jim Kingdon <address@hidden>
>  Subject: Re: CVS and PreservePermissions
>     Date: Thu, 21 Dec 2000 12:46:55 -0500 (EST)
>       To: address@hidden
>       Cc: address@hidden
> 
> (a question that came to me privately, response CC'd to info-cvs)
> 
> > It seems that there are some problems with PreservePermissions code in CVS
> > 1.10 and that the feature has been completely disabled for CVS 1.11
> 
> Yup.
> 
> > I'll be willing to help in order to get this working
> 
> Excellent!  That's all it takes, a programmer with a little time.
> 
> > Do you happen to remember how the PreservePermissions code fits in
> > with the rest of CVS?
> 
> It should be easy to find.  The code which parses CVSROOT/config
> (parseinfo.c) sets a global variable which then it tests every time
> that the code is actually used.  And the code is also in #ifdef
> PRESERVE_PERMISSIONS_SUPPORT (still in 1.11 and development sources,
> just not enabled).
> 
> To make it work well enough to re-enable, you just need to fix the
> hard link code (or disable the hard link code, if you just want the
> rest of PreservePermissions).  I think there is probably a test case
> (or hint at one) buried somewhere in cvshome.org or you can just play
> with it enough a bit - you should hit the hard link bug quickly enough.
> 
> > Would you mind pointing me to any documentation that might
> > explain it, or shed some light on how it's supposed to work.
> 
> Well, cvs.texinfo describes the intended behavior, and I'm pretty sure
> doc/RCSFILES describes the extensions to the RCS file format.

This sounds like it would be perfect, when implemented.

luke