Question

Haven't tracked this one down, but for some reason, i kept getting the following type of errors in my error_log until i added a 'SetEnv USER "nobody"' line in httpd.conf:

ci: /usr/local/apache/twiki/data/Main/WebPreferences.txt,v: no lock set by root

i checked and rechecked, and as far as i can tell, the CGIs are run as nobody, not root, so i don't know where rcs is getting "root".

• TWiki version: Twiki-20001201
• Web server: Apache 1.3.13
• Server OS: Unix

-- TWikiGuest - 16 Jun 2001

Answer

Run the testenv script and you will see what user the cgi scripts are running under. The locks user in the .txt,v files must match the cgi script user. Patch the RCS files if needed. Details in the installation notes.

-- PeterThoeny - 16 Jun 2001

testenv shows scripts running as nobody. As i said everything looks good but something's odd, this was just FYI.

-- TWikiGuest - 17 Jun 2001

I am seeing an intermitant problem of this sort as well. Seems connected to the fact the when apach starts up (for me on FreeBSD) the first proccess is root owned, then the spawned/follow up proccesses are ran by nobody. Just a matter of timeing or something, as I can't pin down what proccess I am going to hit when I do that save... more food for altering this owned by nobody thing.

-- DrewCard - 27 Jun 2001

That could be an Apache prob^H^H^H^Hfeature. When everything is running right I don't think that root-owned process should ever handle an HTTP request. That's what the spawned httpds are for. I notice here on my Apache/Linux installation (running 1.3.19) that there are two root-owned servers, one for the straight httpd and one for the httpd-perl. Could load be a factor? This system is very lightly loaded.

-- RayMcVay - 09 Jul 2001

Changeing Status... I think this needs further discussion.

-- DrewCard - 06 Jul 2001

My setup goes a long time between accesses (hours and days), and I am the only user. So server load just isn't there. And I just got it again, gerr....

During save of file Main.BackdraftDammaged an error was found by the version control system. Please notify your Dammaged administrator. 
/usr/bin/ci -l -q -mnone -t-none -w'DrewCard' /usr/local/www/twiki/data/Main/BackdraftDammaged.txt
ci: /usr/local/www/twiki/data/Main/BackdraftDammaged.txt,v: no lock set by root

Go back in your browser and save your changes locally. 

And when I go back to the testenv script... evrything is fine, httpd ran by nobody.

-- DrewCard - 12 Jul 2001

Just to make sure that we are not ignoring anything obvious here, does any of the TWiki perl scripts have the setuid bit set in the permissions??.

Also, if I understand correctly the problem goes away when you put the line SetEnv USER nobody??. Does your apache configuration file have the lines: User nobody and Group nobody??.

-- EdgarBrown - 17 Jul 2001

Sorry, put the line SetEnv USER nobody where, I don't follow? And yes my httpd.conf has the User & Group lines set to nobody.

• [ EdgarBrown ] The comment came from reading the first couple of lines in this topic. And it is just putting this into the Apache's httpd.conf file.

Just did two page edits in one browser window, got the message both times, opened a new window did another edit, went just fine. All inside of 5 minutes.

-- DrewCard - 18 Jul 2001

I've been seeing similar things under MacOS 10.0.4. (See the "Checkin Failures" part of RCSConfigurationOnMacOSX.) Several times I removed the RCS file and edited a page to see who owned the locks. So far I've seen the locks show up as "www", "root", and "todd". At the moment it seems stable as "todd", which is logged-in on the console. There seems to always be one "root" httpd and two "www" httpd processes. Adding a bunch of logDebug calls in twikistore.pm shows that both the actual and effective UIDs are "www" as far as the CGI scripts are concerned. I'm wondering if perhaps RCS, when trying to determine the invoker's UID, is somehow getting the wrong one.

This is a Mac OS X problem. See my workaround in RCSConfigurationOnMacOSX. -- JonReid

In the process I've noticed that wikistore.pm does absolutely no error checking around the RCS calls. Perhaps the new beta does it better. If not, perhaps I'll contribute some code.

-- ToddJonker - 18 Jul 2001

I guess you might have found the problem Todd, would you check if your rcs commands: rcs, ci, co and the like have setuid privileges, that is if an ls -l on the corresponding commands show an 's' flag on user permissions, with a user of 'root'??.

If that is the case, rcs could change to whatever user it wants, and it seems to get confused and changes to whoever is logged into the console, from the rcs manpage: Do not use other setuid commands to invoke RCS commands; setuid is trickier than you think!. You can remove this behavior by using chmod gu-s on the corresponding commands (my instalation doesn't use it, but yours might depend on that).

If that is not the case, then the program that calls the rcs commands (apache->twiki->rcs), has to have such user assigned to it, the operating system cannot be changing permissions randomly (if it does, it's a HUGE security hole).

-- EdgarBrown - 18 Jul 2001

Good thinking, Edgar, but it doesn't look good. None of the RCS, perl, or TWiki commands are setuid. The TWiki scripts are currently owned by 'todd' and are all -rwxr-xr-x but that shouldn't matter, right?

-- ToddJonker - 19 Jul 2001

You are right, who owns the twiki scripts should not matter as long as these have no setuid privileges.

So given that you have tested that Apache itself is calling the twiki sources as www, the only option that I see (besides a kernel/filesystem bug) is that the rcs files are inheriting the owner of the directory (which could be enforced by an s permission in the user/group field of the parent directories, but otherwise would seem like you have a bug in your hands).

As you have root access to your box, I would just change all the files and directories in the twiki to be owned by Apache (in your case www), you can leave the binaries as they are. Then change the file permissions to -rw------- or drwx------ for the directories, the twiki would still work as it will be executed by the right user. If ownerships are still jumping around, you should post a bug report to the Darwin/OS-X folks.

-- EdgarBrown - 19 Jul 2001

For now, this is just a note to myself to check some things -- the directories in my home TWiki (the 20010315 beta) and, IIRC, the ones on SourceForge (WikiLearn, not really working yet, but created by copying twiki.org), all seem to have the permissions drwxrwsr-x. (I didn't ssh to SourceForge today to check this.) Also, it seems I had some problem when I changed them to something without the s, but I forget what. Question is, do I need to change these? (I probably will have to experiment, see what the problem is without the s.)

Update: I checked SourceForge -- the directories I copied from twiki.org have the s set (drwxrwsr-x or similar). (The ones I created do not have permissions (or ownership) set properly yet.)

(Frustrating thing is that I forgot the syntax of the ssh command for SourceForge, and I don't yet have it stored on my twiki -- that's part of what my twiki is for!! Hmm, maybe I should put that info on SshToSourceForge (and my twiki).)

-- RandyKramer - 20 Jul 2001

No you don't need to change your permissions, I was just making suggestions on debugging the rcs permission problem in Todd's and Drew's instalations.

The "s" permission in the directory's group just forces all directories and files created under itself to belong to the same group as the original directory, this is useful if you want to give ownership to, let's say, Apache while at the same time keep all files under one of the groups you belong to (and you see why this would be necessary in SourceForge), so that you can modify them (without making the files world-writable). However if you have root access to the box it is not really needed, it just makes things a little more convenient in general.

This is not needed for TWiki to work, as long as all files are owned by the web-server user (apache, www, or nobody as it might be), and the rcs (xxx.txt,v) files are locked by that same user.

[ RandyKramer -- 22 Jul 2001 ] -- Edgar, Thanks for the explanation of the s!

-- EdgarBrown - 20 Jul 2001

No suid items here, as far as I can tell. Odd, Looking at the xxx.txt,v files I see the the lines:

locks 
     carda:1.5; strict; 

Near the top of the file. I am not an rcs expert of any kind (let alone a twiki expert...) but what about doing away with strict locking? Or even changeing twiki so that these files can be owned better (ie not writable by nobody).

-- DrewCard - 21 Jul 2001

I'm not sure about the strict locking, but given that the TWiki itself is the only one that should be messing with those files (and that if not you would be modifying the same copies anyway), I don't really see why not.

Changing the ownership of the files is a different problem, if we change that, then at least the twiki save script would have to be a setuid script, and I'm sure that even though it would be a nice security feature (if implemented correctly), it would also be a configuration debugging and support nightmare. Not to mention rising the bar for who would be able to install a TWiki.

Maybe when the back-end storage for twiki (CVS and the like) are implemented this would be a different issue.

But back to the original problem. If the files are locked by the user "carda" and twiki tries to change them using rcs under the user nobody, rcs will generate an error. you might want to change that (if my memory is right the twiki instalation documents have a way to deal with that, but I remember just taking a quick look at the man pages for the rcs command ci, and that cleared it up).

-- EdgarBrown - 22 Jul 2001

Check out TWikiOnWindows :^)

-- MartinCleaver - 23 Jul 2001

See RcsNonStrictLocking

This should fix the problem.

-- ColasNahaboo - 30 Oct 2001

See also similar problem RCSStuckVersion