Question

I am asking this as a support question because there may be a well known way to avoid this problem. But, it is arguably a bug that may be fixed (if not already).

This is related to RefreshEditPage and ViewAfterSaveCachesOldPage, in that a similar problem is manifest: after an edit, the save button is pressed, but the save appears not to have been performed. Going back, and pressing it again, and the save appears to be done.

However, the problem seems to have a different cause, specifically, file permissions.

Scenario:

The webserver, and hence the TWiki scripts, run as user www/group G. The twiki/data/* directories are read writeable to the group "G".

A suitably privileged user U - not the wiki admin (me), but a similar power user - copied files into the data/* directories, using a script that converted them to a wiki like format. These files ended up owned by user U, group G, with permissions rw-r--r-- --- i.e. user U read/write, but read-only to group G.

Somebody then attempts to edit the page using TWiki. The twiki web user www can read the file, but when it comes to saving, Store.pm saveFile does an open(">$name") - i.e. it attempts to write INTO the file. The file user U rw/group G ro, the webserver is user www/group G; the webserver cannot write into the file. So the save does not get done (and the appropriate error message occurs inthe log).

However, the second time the save is tried, it works. During the first save attempt, the saveFile to the .txt file fails, and that is what is used to display; but then, after the saveFile, TWiki sees that the RCS ,v file doesn't exist, so it checks the (old, unchanged) stuff in, and then checks it out again, replacing the original file (because RCS uses ONTO semantics). So, the save fails, but creates the RCS file and replaces the .txt file; and thereafter the .txt file has okay ownership and permissions.

This is a very familiar sort of problem to people who have worried about security, RCS, etc. - writing INTO vs. ONTO a file. INTO means using the existing file; ONTO means deleting the existing file, and creating a new one. ONTO is allowed in more circumstances than INTO. Many tools, such as RCS variants, had to be adapted to use ONTO file writing rules.

But, ONTO writing loses group ownership and permissions info that INTO might preserve.

I am not quite sure what is the right thing to do. However, I note that, since TWiki uses a random mix of INTO and ONTO rules, consistency might suggest going all one way or all the other; probably, all the way to ONTO, since that's what many RCS tools do.

Now, plainly, this would not be a problem if users who can write the twiki/data directories were careful about group write permissions.

But, nevertheless, it is a problem that appropriate coding can eliminate.

Arguably, one should nota llow direct access to the twiki/data/*/* files. But, if I wanted that, I would be using Zope. The biggest reason I chose TWiki was the fact that the files could be munged.

Here's the question: I had had some hope that setting the directory group sticky bit would avoid the problem, but, while that correctly propagates group ownership, it does not propagate permissions: the users umask, and the umask of tools that write files, often takes precedence.

Q: is there any other way to enforce the appropriate group read write permission?

Or, should twiki be changed to consistently use ONTO rather than the present random mix of INTO+ONTO file writing semantics?

• TWiki version: (TWiki version: 01 Feb 2003)
• Perl version: 5.6.1
• Web server & version: Apache
• Server OS: SunOS?? + Linux
• Web browser & version: Internet Explorer 6.0
• Client OS: Windows XP

-- AndyGlew - 30 Apr 2003

Answer

I noticed that problem myself after copying a text file into a data directory.

Since it is a not standard way to copy files into TWiki on the file level I consider it the resposibility of the administrator to make sure that the file permissions are correct.

Consistently using ONTO sounds like a logical thing to do. However, performance needs to be addressed. An open(">$name") is faster then a delete, followed by a create. But this is possibly negligible. If you want you could provide a patch in the Codev web.

-- PeterThoeny - 01 May 2003

It would also be useful to have a configurable umask in TWiki.cfg - currently I think the umask is just inherited from the web server's, which may not always make sense.

-- RichardDonkin - 01 May 2003

Actually, TWiki's code has explicit umask calls scattered throughout it. Some umask(0), some umask(2) - and in still some other places it seems to use the value inherited from the user. Frankly, it looks like there have been a number of problems in this area, and they have been fixed in an ad-hoc manner. Whether it is consistent or not, I do not know. ... I wish that the test suite contained a test for every problem that was fixed by such a umask change. I don't like thinking I may be breaking something.

-- AndyGlew - 01 May 2003