Question

Hello,

I am trying to set up Twiki on a shared server which has lots of other users. I do not have root access on the machine. Since we will be discussing somewhat sensitive research topics, we want the following "security" requirements:

• No other user with an account on the server should be able to view the files.

• No other user with an account on the server should be able to modify the Twiki.

• Only users for whom we have set up a TWiki account should be capable of viewing/modifying the Twiki data. I was thinking of manually creating an .htaccess entry for each new user we want to allow. This way, the complete twiki directory structure can be reasonably private.

This is probably against the general philosophy of TWiki, but this is something which I cannot do anything about. The problem with implementing this security policy on a shared server are:

• In order for the twiki data to be unreadable/unmodifiable by anyone on the server, we would want these files protected with something like chmod -R go-rw pub and chmod -R go-rw data inside the twiki directory. Unfortunately, Twiki doesn't work in this case since the Apache web server is also unable to view/modify the files.

• We thought of 'setuid'ing the cgi scripts to be owned by the user in whos directory the twiki was residing so that the CGI scripts could still be able to read/modify the files. This works for viewing, but whenever a new file is created, I get the following RCS error:

ci: /home/eecs/srinath/HTML/twiki/data/Sandbox/TestTopic1.txt: setuid initial checkin prohibited

At this stage, a file called TestTopic1.txt is created in the correct directory, but the TestTopic1.txt,v file is not created. This is the same error mentioned in PermissionDeniedWithSetuidPerl, but there was no solution found.

Environment

-- TWikiGuest - 03 Aug 2005

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

I do not think that it is possible at all to secure your TWiki in this configuration, even if you solve the setuid problem.

Since the web server must be able to execute the view, edit etc scripts, also everybody who can su to the web server can also start this scripts manually, after setting some environment variables like PATH_INFO, QUERY_STRING and especially REMOTE_USER, which would fool your access control system.

Furthermore, anybody who has write access to the configuration file of the web server can configure the server such that it ignores your .htaccess files and even worse performs a new authentication method for the same userids!

A probably better method would be to set up your own web server. Since you do not have root privileges the server must run on a non-privileged port like 8000 (or anything you like > 1000). Of course, this does not work if you are behind a firewall and if you cannot convince your sysadmin that you do need a secure server.

-- JChristophFuchs - 05 Aug 2005

there was discussion (and possibly an implementation) of encrypted topics

unfortunatly I don't know were. Both this, and the idea of storing the topics elsewhere from the TWiki server would currently require some development work by you (and I'd suggest that DevelopBranch would be the better place to start if you want to implement a secure store system)

-- SvenDowideit - 05 Aug 2005

Hi JChristophFuchs,

I think there is a mis-understanding. I never wanted to keep the TWiki safe from a person who has root access to the server. That is impossible and I know it. After all, root can casually delete my web-space without having to go through the whole QUERY_STRING bussiness.

I want to protect the TWiki from non-root users who also have accounts on the web-server. I do not see why this is impossible if the setuid problem is solved. Then since the TWiki CGI scripts run as me, the pub/ and data/ directories need only to be readable/writable by me.

SvenDowideit's suggestion of encrypted topics looks like a perfect long-term solution. However, I unfortunately, do not have the time/experience to contribute in that regard.

-- SrinathAvadhanula - 11 Aug 2005