Question

Although I have figured this out on my own, I thought that I'd ask it as a question, to try to find out if there is a better way.

I have set up twiki on a multiuser system where I am not root, where I am not a sysadmin, etc.

I want to set up several twikis for different projects. The projects want access control, both at the TWiki level, but also for the twiki/data files stored on the UNIX fileserver.

Our Apache httpd runs as user "www", group "www". Therefore, by default, TWiki creates files owned by www/www.

This is inconvenient because I cannot always delete files owned by "www". (Well, actually, I can, but it involved creating a cgi script to break security.)

It is also inconvenient because the www/www files are not readable by most users, who are not in group www.

This last is somewhat assuaged by putting httpd in a more public group, "design", and using setgid directories so that the wiki files are owned by www/design. But then, everyone can read all the twiki files. So much for access control.

What I am doing now is using setgid wrapper programs to groups specific to each project using twiki. These wrappers run, and then exec the twiki Perl scripts, which then have a more restricted group id. E.g. they run as user "www", group "projectgroup", and such is the ownership of their files.

This gives me a world where members of the project can read the files using ordinary UNIX tools, but people who are not members of the project cannot.

Q: is there a better way?

• 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 - 11 Apr 2003

Answer

The best solution here is to use suexec or similar as mentioned in SecureSetup - my web host does this and it works well for my TWiki site at http://donkin.org/. Getting this set up may be somewhat difficult, permissions and ownership of scripts are very important - however what you end up with is a setup where all data files can be owned by user fred, group mygroup, which is a step closer. You might need to pay attention to the umask actually used, i.e. to ensure group can write to such files.

-- RichardDonkin - 12 Apr 2003

I've run into similar issues recently.

Requirement 1: manage twiki on unix from non-root account. Obviously, the twiki admin(s) need to be in www group. (If you can't be in this group then use suexec as above.)

Requirement 2: Other unix users need access to twiki data or pub dirs. (I consider this an invalid requirement.) Unix users can access twiki data through shell-level web tools. So they should use curl or lynx or webget to access twiki through apache and can then save or pipe into whatever other tools they like. They should never act upon the twiki data or pub (or any other directory) files themselves. If the unix users want access to the raw twiki text, or other revisions, it can be done through the URL. If the unix users want to POST back to twiki, that should also be done via apache. This guarantees coherency of the twiki "database".

Requirement 3: project manager insists on being in group www in order to 'maintain' a project web. (I consider this an invalid requirement, unless the project manager is a qualified unix admin.) All content-level admin stuff should be done through twiki itself. If the webs have been created with a long-range content plan in mind, there's no need to create new ones or rename them for short-term projects. For special types of administration which aren't able to be performed via normal twiki actions, new and simple CGI scripts can be created and a simple interface with a few radio buttons for different customized pre-defined actions works well (example: web backup to local PC, zip and download all attachments to specific topic, etc). Any other actions should be done by the real unix admin!

-- JonathanCline - 14 Jul 2003

While I sympathize with the suggestion made under JonathanCline's requirement #2, that all twiki file access be via the web - specifically, I sympathize with the desire to keep the TWiki databasse consistent - I reject it.

One of the big reasons why I chose TWiki was that it uses ordinary UNIX files, and ordinary UNIX tools such as find can be used to access it.

If I wanted a consistent database, I would have continued to use Zope/ZWiki, where, because the topic pages are maintained by a database, consistency is maintained by standard database mechanisms.

One way to avoid consistency problems is to avoid fragile assumptions about consistency. That is the UNIX way, for "databases" maintained in files.

Q: what assumptions about consistency does TWiki make? Are they necessary? Can they be eliminated?

-- AndyGlew - 16 Jul 2003