info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cvs commit/up's change file ownership in working dir.


From: Patton, Matthew E., CTR, OSD-PA&E
Subject: cvs commit/up's change file ownership in working dir.
Date: Mon, 5 Jan 2004 14:01:01 -0500

Classification: UNCLASSIFIED

I have a file owned root.named. root wasn't a member of said group but I
tested with root being a member (not primary group) and it still does the
same thing (if 'named' were the primary group for 'root' I'd be ok in this
one very narrow instance). When I commit a file, cvs is changing the file
ownership to the default for that account: namely root.root which destroys
my setup. I think we need to move beyond simply creating in the working
directory a file owned by whatever fopen(2) comes up with. My repository
files are owned by entirely different users and groups and have no bearing
on what is in the working dir and have a 0440 visibility to keep unneeded
noses away from RCS files. Because that's the way they have to be.

In order that I don't have to go traverse the repository for files that are
NOT 0440 I set CVSUMASK=027 for the user checking in. Unfortunately this
also means that ANY checkouts will apply the repository's permission bits to
the working set which is just silly. We can't on one hand say what goes on
in the repository is entirely separate and irrelevant to the working set
like it was suggested about the use of internal RCS revision numbers, or
requiring the user to take their own steps to "initialize" a build
environment with supplemantary scripts instead of storing meta-data within
the RCS files, yet turn around and let repository file permissions influence
the working set. Which is it going to be? IMO we *should* support such
obvious and useful meta data as file modes and file ownership with the full
understanding that this is not as entirely simple as one would hope. 

Does anyone actively use the PRESERVE_PERMISSIONS_SUPPORT capability? Is it
being maintained? My quick look thru the source says it stuffs "owner,
group, permissions" as fields into the RCS file. And it also appears that it
stores the numeric value of uid/gid which is an immediate problem when you
consider that these values are not portable from one machine to another let
alone different OS's. We need the textual representation if nothing else. In
any event the values are derived from the working file's attributes which in
my mind quickly poses significant problems in real life.

For example if "joe" and "todd" are editing files, whoever commits last
could end up setting "file owner|group; " to their uid/gid because that's
how the file is in their working set. If 'jane' does a 'cvs up' her files
will have to be owned by her because I'm pretty sure she won't be 'root' and
thus able to chown/chgrp arbitrary file owners ('joe' or 'todd') to her
files.

Permissions are more challenging. Sloopy 'joe' can't be bothered with
security so he just mode 666's every file he deals with. So when he checks
in a file and 'todd' updates his working set, todd gets a bunch of mode 666
files which he desperately doesn't want. (plus there's the little matter of
OS's with non-unix conventions) So who gets to set uid/gid/mode? Do we
subtract umask from whatever value was last set by he who checked in? What
if 'security Todd' decides every file should be 600. We still have a
problem. ok maybe we take this out of the users hands entirely. only 'cvs
admin' can set owner,group,mode and cvs will make a best effort to comply on
checkout/update (but never in check-in/commit) in so much as the uid running
cvs is able. Furthermore the admin can set repository or project-wide
defaults should it be desired. 

There was some discussion about using CVS and files in /etc back in 2001 but
I didn't see any real solution presented except to say CVS couldn't give a
rip, it's not relevant, CVS shouldn't deal with meta-data, and so forth -
and if you want it, write a script to set perms on checkout. But this is a
non-solution and ignores IMO a legitimate need. And yes I can use mtree and
a file spec to implement it should I have to go that route.

Thoughts? But the first thing that has to happen regardless is tossing the
derivation of file modes in the working set from whatever the repository
happens to have. The patch below takes care of that I think. The source is
from v1.11.9

--- rcs.c.orig  2004-01-05 13:37:40.000000000 -0500
+++ rcs.c       2004-01-05 13:58:08.000000000 -0500
@@ -4610,10 +4610,14 @@
                       workfile);
        }

-       ret = chmod (workfile,
-                    change_rcs_mode
-                    ? rcs_mode
-                    : sb.st_mode & ~(S_IWRITE | S_IWGRP | S_IWOTH));
+       if (change_rcs_mode)
+       {
+           if (chmod (workfile, rcs_mode) < 0)
+               {
+                   error (0, errno, "cannot change mode of file %s",
+                       workfile);
+               }
+       }
 #else
        if (fclose (ofp) < 0)
        {
@@ -4621,14 +4625,7 @@
            return 1;
        }

-       ret = chmod (workfile,
-                    sb.st_mode & ~(S_IWRITE | S_IWGRP | S_IWOTH));
 #endif
-       if (ret < 0)
-       {
-           error (0, errno, "cannot change mode of file %s",
-                  workfile);
-       }
     }
     else if (sout != RUN_TTY)
     {




reply via email to

[Prev in Thread] Current Thread [Next in Thread]