[Top][All Lists]

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

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

From: Todd Denniston
Subject: Re: cvs commit/up's change file ownership in working dir.
Date: Tue, 06 Jan 2004 13:48:18 -0500

"Patton, Matthew E., CTR, OSD-PA&E" wrote:
> Classification: UNCLASSIFIED
> > From: Kaz Kylheku [mailto:address@hidden
> > Read up on the setgid bit on directories.
> I have extensive use of setgid on my REPOSITORY. setgid is not a solution
> when managing things like /etc/*.
> > > I think we need to move beyond simply creating in the working
> > > directory a file owned by whatever fopen(2) comes up with.
> >
> > No we don't. The POSIX operating system interface is designed
> > such that
> > programs can use the fopen() function without worrying about
> > it. It does
> > the right thing based on the process security context, umask, and
> > permissions of the directory.
> ...
> > Versioning permissions is a bogus idea. When you check out files, they
> > should be created such that they are accessible to you.
> Then my patch to eradicate the chmod'ing of checked out files based on the
> respository's file perms is all the more necessary - who came up with that
> one anyway? 
>  My little example describes
> just one of a few problems wherein CURRENT implementation of
> PRESERVE_PERMISSIONS would end up overwriting the perms/mode of a file with
> whatever person was last mucking with it. Again, I repeat that I simply want
> to store a perm+mode attribute in the RCS file so that when it's checked out
> it gets those perms unless of course the euid of the process (eg. non-root)
> can not actually do the chown/chmod in the working directory. I don't care
> about these latter failures.

As Larry indicated the PRESERVE_PERMISSIONS_SUPPORT was found to not work as
it was expected, and thus (from my perspective) it was marked in a way to
allow it to atrophy.  Why it has not been completely removed yet is unknown to
me, perhaps it is something to look forward to with the final 1.12.X release.

I suspect from your first email you have read some of the list archives that I
have below[1-5].

I believe the wall you are hitting with your patch is due to three things:

1) As Larry mentioned in "Re: cvs ci, cvs upd: Hard linkage problem" [2] you
need to "include test cases in to verify that the functionality
works and continues to work in the future" and better to have those same ones
crash/break/fail under the current code.  Which is also mentioned in the
HACKING file under "Writing patches (tactics)"

2)  Everyone else using CVS has found that it is much easier/saner to manage
file permissions and ownership using a build tool of some sort, and even
specifically for /etc [3,4,5].  Some even give, what I see as, good reasons to
keep permissions out of CVS, see Kaz Kylheku's responses [5].

3)   Because PRESERVE_PERMISSIONS_SUPPORT code as a whole "is notoriously
buggy and contains at least one known problem that can cause unrecoverable
data loss"[6] and has been for quite some time, (my opinion only) no one wants
to even accept a patch to it that does not fix it all and accept maintainer
ship for the long haul.  The original (cleaned up) vision for Preserve
Permissions can probably be seen in the references from Jim Kingdon's

[1] Subject: Re: CVS and PreservePermissions

[2] Subject: Re: cvs ci, cvs upd: Hard linkage problem

(I wish had most of the pre mid 2000 posts. From time to
time I find many good answers in my personal archive back through Dec. 99, and
can not reference them online.)

[3]Subject: Re: CVS management of /etc - permissions problem

[4] Subject:  Re: using cvs to contol system files

[5] Subject: Re: CVS management of /etc - permissions problem

[6] from Larry Jones. I am pretty sure Larry got tired of typing this and has
it in a permanent cut and paste buffer somewhere as it is the same (or almost
so) each time preserve permissions comes up.

reply via email to

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