"Patton, Matthew E., CTR, OSD-PA&E" wrote: > > Classification: UNCLASSIFIED > > > From: Kaz Kylheku [mailto:[EMAIL PROTECTED] > > > 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? <SNIP> > 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. > <SNIP>
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 sanity.sh 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 email[1]. [1] Subject: Re: CVS and PreservePermissions http://mail.gnu.org/archive/html/info-cvs/2000-12/msg00378.html [2] Subject: Re: cvs ci, cvs upd: Hard linkage problem http://www.faqchest.com/prgm/cvs-l/cvs-00/cvs-0005/cvs-000505/cvs00051019_22271.html (I wish mail.gnu.org/archive 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.) (solutions) [3]Subject: Re: CVS management of /etc - permissions problem http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00353.html [4] Subject: Re: using cvs to contol system files http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00352.html http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00351.html [5] Subject: Re: CVS management of /etc - permissions problem http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00348.html http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00373.html [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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
