Xref: utzoo comp.unix.wizards:24219 comp.unix.questions:28922 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: The new 5.5 version of RCS, as a setgid program. Summary: It behaves in strange ways. Message-ID: <1991Feb22.025128.9928@mp.cs.niu.edu> Date: 22 Feb 91 02:51:28 GMT Sender: rickert@mp.cs.niu.edu (Neil Rickert) Organization: Northern Illinois University Lines: 48 Note: This is not intended as a complaint. Version 5.5 of rcs has some nice features compared with earlier ones. It's just at the sgid feature isn't quite what I expected. ----- Here is the situation. rcs 5.5 is installed 'sgid rcs'. I create an RCS subdirectory. I put it in group 'rcs', or persuade the sysadmin to do this for me. I make the directory group writeable, but not 'other' writeable. Provide I have write access to the directory, I can check in a new program, say NEW.c. Then I can use 'rcs' to set up an access list. Because of the sgid attribute, anyone on the access list can check revisions in. But they can't use 'rcs' to outdate a revision. So far, so good. But what stops user 'somebody' who is on the access list from checking in a new revision, or even just checking out and locking the current revision. Then, because he now owns the RCS/NEW.c,v file he can chmod it, and copy /dev/null to it, thereby removing ALL revisions. I tried creating user 'rcs' and making the system also 'suid' to rcs. But then I can't even check something in. Presumably if I use suid root, it is OK, but that is a dubious practice. (My hope had been that the system would work exactly as without the 'suid rcs' setup, but the archive file would be owned by 'rcs' instead of the user who last changed it, thus preventing obliteration). Well, it turns out if I remove the 'o+x' permission from the RCS directory, although 'somebody' can check in and check out revisions, he can no longer obliterate them. But unfortunately 'make' can no longer compare the dates to decide whether an automatic checkout is needed. If, as well I turn off the 'o+r' bit, at least 'make' doesn't complain. 'somebody' would have to manually do rlog or rcsdiff etc to be sure he has a current version. Question: Was there a better method I could have tried? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940 Brought to you by Super Global Mega Corp .com