• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

The current file permissions work out of the box only for shared hosts using suExec (such as Dreamhost). This is not a typical server environment for the target users of TWiki. I suggested change the permissions to make install easier on a variety of platforms, without compromising the security. See the many installation issues faced below on a manual install.

What From To Comment
bin/ 755 755 (no change)
bin/.htaccess.txt 440 444 to avoid read error by Apache
bin/LocalLib.cfg.txt 650 644 to avoid read error by scripts
bin/attach 550 555 for all scripts, to avoid read error by Apache
bin/logos/warning.gif 440 444 for all images, to avoid read error by Apache
data/Web/ 755 755 (no change)
data/Web/Topic.txt 640 644 for all topics; same as topics created by TWiki
data/Web/Topic.txt,v 440 and 400 444 for all topics; same as topics created by TWiki
lib/TWiki/ 755 755 (no change)
lib/LocalSite.cfg.txt 440 444 to avoid read error by cgi script user
lib/TWiki.spec 440 444 to avoid read error by cgi script user
lib/TWiki.pm 440 444 recursively for all modules, to avoid read error by cgi script user
locale/ 755 755 (no change)
locale/TWiki.pot 440 444 to avoid read error by cgi script user
locale/da.po 440 444 for all files, to avoid read error by cgi script user
pub/TWiki/ 755 755 (no change)
640 644 for all files; same as attachments created by TWiki
templates/ 755 755 (no change)
templates/addform.tmpl 644 and 440 444 for all files; to avoid "installation error" message caused by read error by cgi script user
tools/ 755 755 (no change)
tools/geturl.pl 550, 440 and 750 444 for all files; to avoid "installation error" message caused by read error by cgi script user

Below are typical installation issues people can face on a manual install caused by the the current permissions.

-- PTh

File permission issues, e.g. data/TWiki :

-rw-rw----   1 pthoeny  twikidev   20473 Dec 10 15:04 ATasteOfTWiki.txt
-r--r--r--   1 pthoeny  twikidev   58400 Dec 10 15:04 ATasteOfTWiki.txt,v
-rw-rw----   1 pthoeny  twikidev    1093 Dec 10 15:04 AccessKeys.txt
-r--r--r--   1 pthoeny  twikidev    2382 Dec 10 15:04 AccessKeys.txt,v
-rw-rw----   1 nobody   twikidev    5395 Dec 10 15:04 BehaviourContrib.txt
-r--r-----   1 nobody   twikidev    5593 Dec 10 15:04 BehaviourContrib.txt,v

.txt should be 644, .txt,v should be 444, the default permissions used when TWiki creates topics.

-- PTh

All topics have been 660 for a long time.

It is not the build script. It is defined like this in the tools/MANIFEST for each and every file.


There are more inconsistencies, twiki/templates :

-rw-r--r--   1 pthoeny  twikidev      36 Dec 10 14:59 addform.nat.tmpl
-r--r-----   1 pthoeny  twikidev     169 Dec 10 14:59 addform.pattern.tmpl
-r--r-----   1 pthoeny  twikidev     179 Dec 10 14:58 addform.tmpl
-rw-r--r--   1 pthoeny  twikidev    1851 Dec 10 14:59 attach.nat.tmpl
-r--r-----   1 pthoeny  twikidev    7971 Dec 10 14:59 attach.pattern.tmpl
-r--r-----   1 pthoeny  twikidev    2384 Dec 10 14:58 attach.tmpl
-rw-r--r--   1 pthoeny  twikidev    1346 Dec 10 14:59 attachagain.nat.tmpl

-- PTh

What is the reason for using 644 and 440 for templates, 660 for .txt, and 444 and 440 for .txt,v files? Specifically, the '0' for 'others' can be a installation issue, and does not add much security.

This gives an installation error if for security template files are owned by a non-Apache user.

-- PTh

More inconsistencies, twiki/bin :

-r--r-----   1 pthoeny  twikidev    4510 Dec 10 14:58 .htaccess.txt
-rw-rwx---   1 pthoeny  twikidev    1419 Dec 10 14:58 LocalLib.cfg.txt
-r-xr-x---   1 pthoeny  twikidev    1057 Dec 10 14:58 attach
-r-xr-x---   1 pthoeny  twikidev    1073 Dec 10 14:58 changes
-r-xr-x---   1 pthoeny  twikidev   19842 Dec 10 14:58 configure
drwxr-xr-x   2 pthoeny  twikidev     512 Dec 10 14:58 logos
-r-xr-x---   1 pthoeny  twikidev    1079 Dec 10 14:58 search
-r-xr-x---   1 pthoeny  twikidev    1892 Dec 10 14:58 setlib.cfg


  • setlib.cfg cannot be read by Apache user, resulting in a Can't locate setlib.cfg in @INC message
  • The 440 of .htaccess.txt is likely to result in an installation issue when copied with same permissions to .htaccess
  • The 550 of scripts result in a Permission denied error message

-- PTh

More in twiki/lib :

-r--r-----   1 pthoeny  twikidev    2912 Dec 10 14:58 Assert.pm
drwxr-xr-x   3 pthoeny  twikidev     512 Dec 10 14:58 CPAN
-r--r-----   1 pthoeny  twikidev    2173 Dec 10 14:58 LocalSite.cfg.txt
drwxr-xr-x  13 pthoeny  twikidev    1024 Dec 10 14:59 TWiki
-r--r-----   1 pthoeny  twikidev  119980 Dec 10 14:58 TWiki.pm
-r--r-----   1 pthoeny  twikidev   50553 Dec 10 14:58 TWiki.spec

440 modules can't be read by Apache unless in same group. A 444 permission for .pm files is fail safe and secure.

This gives an installation error if for security perl modules are owned by a non-Apache user.

-- PTh

Inconsistancies should naturally be addressed. I really do not understand why you have problems running with the default access rights.

I notice that your files are owned by pthoeny. Why are they not in general owned by the apache user? The installation suggests changing the ownership of the apache directory to the apache user.

The way the default settings are now TWiki works out of the box on a RedHat Linux by installing TWiki in /var/www/twiki and only changing the ownership of the entire /var/www/twiki tree to apache. And I guess that must be the most standard/normal kind of installation we have. Standard Linux box with standard location for Apache.


[15:04] PeterThoeny: hmm, again a permission issue
[15:04] PeterThoeny: easy to fix, but...
[15:05] PeterThoeny: ...we need to address Bugs:Item3280
[15:05] twikibot_: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3280
[15:06] PeterThoeny: just the other day i installed twiki on a redhat enterprise system
[15:07] PeterThoeny: for security i want to have all bin, lib. template files owned by a 
        non-apache user
[15:07] PeterThoeny: unfortunately that means that an out of the box twiki does not work
[15:07] Lavr: And then you make all the files world readable??
[15:07] PeterThoeny: i had to make all files o+r
[15:07] PeterThoeny: yes, as all cpan modules are
[15:07] PeterThoeny: and all linux libs
[15:08] Lavr: I am thinking about the topics. I have no problem with world readable libs.
[15:08] PeterThoeny: i thing locking down files for others hinders security in general
[15:08] PeterThoeny: for one special case only it enhances security: in a shared host env 
        with suexec
[15:09] PeterThoeny: but this case is very special, and not typical for the target users 
        of twiki
[15:10] Lavr: Well. It is also typical that Unix boxes allows almost anyone to login to 
        other Unix boxes. And then they can read all the topics in the Twiki data dir.
[15:10] Lavr: Also the ones they are not supposed to read.
[15:10] PeterThoeny: imho the current default permissions are danerous becuase un 
        inexperienced user is tempted to do a 777 to all dirs and a 555 to all files
[15:11] PeterThoeny: just to get twiki work
[15:11] Lavr: But if the data dir and pub dir are owned by Apache and the lib dir is 
        owned by root or user then it is not a problem to make the lib dir world 
        readable. Except the password file which is now exposed.
[15:11] PeterThoeny: so, for better security i think we should change all files to be 
        world readable
[15:13] PeterThoeny: if non-it folks can login to the twiki server,
[15:13] PeterThoeny: the data dir and pub dir should be protected with a 770
[15:13] PeterThoeny: and owned by the apache user
[15:13] PeterThoeny: actually, a 750
[15:17] Lavr: I think in those cases where people can login on a UNIX box world readable 
        data files is a security issue. On a system with just one and the same root user 
        the entire focus should be to protect against attacks from outside via the open 
        http port.
[15:18] Lavr: I think we are in the situation that we are dammed no matter what we do. 
        But access rights issues are the most common issues people have with installing 

[15:39] PeterThoeny: kenneth, do you see an issue if we make all files o+r?
[15:43] Lavr: Yes and no. IN REALITY the way TWiki has been shipping the last years the 
        default has been....
[15:44] Lavr: 1. All the data files in the distrubution were not world readable.
[15:44] Lavr: 2. All the new data files that people add are world readable.
[15:44] Lavr: So the current default security is bogus. At least we should be consequent.
[15:45] PeterThoeny: actually, cairo shipped with world readable files
[15:45] PeterThoeny: this change was recent, in dakar
[15:45] Lavr: To correct this it is a lot of MANIFEST files to edit. Also plugins!!
[15:46] PeterThoeny: yes
[15:46] PeterThoeny: not for rc1
[15:46] PeterThoeny: but for rc2 if we agree
[15:46] Lavr: I can live with it but then we do TWO additional actions.
[15:47] Lavr: 1. We add a link to INSTALL.html to a supplemental page that recommends 
        different setups for different situations.
[15:47] PeterThoeny: that supplemenal page is your permission generator
[15:47] Lavr: 2. The obvious - the supplemental index page which already now can link 
        to the permission   YES
[15:48] PeterThoeny: that page can be enhanced with a flag suxec env yes or no
[15:48] Lavr: The permission page is just a simple text page. Not as smart as 
[15:48] Lavr: We already link to ApacheConfigGenerator from INSTALL.html
[15:48] PeterThoeny: yes, i was talking about the apache config gen page
[15:49] Lavr: And it has helped a lot of people.
[15:49] PeterThoeny: yes
[15:49] Lavr: We can do the same with setting file access rights.
[15:49] PeterThoeny: i think a sensible approach is to mention the suexec case in 
        install.html and installation guide, with pointer to your apache config 
        generator topic
[15:50] PeterThoeny: that way we cover this special case well
[15:50] Lavr: I do not have any experience with suexec so there I need some help.
[15:51] PeterThoeny: for the generator, you can simply assume that under suexec there 
        are many apache users, one for each account, so a o-r is appropreate, else in 
        normal case a o+r
[15:52] Lavr: In suexec - does all the scripts run as the user or does some things act 
        like Apache?
[15:54] PeterThoeny: i think all script run as the user
[15:55] PeterThoeny: so, i suggest to have data and pub files o-r or o+r, depending on 
        suexec flag (also dirs)
[15:55] Lavr: Then the ownership of the files should be the user and still not world 
        readable I would think. But I have a feeling that there is a glitch and that 
        not all is done as owner. E.g. passwords may be read as Apache
[15:55] PeterThoeny: and all other twiki files (templates, lib, tools, bin) o+r
[15:57] PeterThoeny: hmm, yummy, since last week we get frey chocolate from the local 
[15:57] PeterThoeny: they have a very tasty cafe & cacao one
[15:57] PeterThoeny: frey is chocolate from switzerland
[15:58] Lavr: I think we should set the different use cases up in a table. It is 
        impossible to overview what is right otherwise.
[15:58] Lavr: And then decide what is the best for each..
[15:59] Lavr: And based on that create the script people can run that sets the user 
[15:59] PeterThoeny: sounds like a plan
[15:59] PeterThoeny: codev topic is best i think
[15:59] Lavr: Yes

-- PTh

We will let TWiki:TWiki.SettingFileAccessRightsLinuxUnix be the topic that INSTALL.html points to. Either we will change it to an index page or to an application like ApacheConfigGenerator.

I will already now checkin the INSTALL.html change. Then we do not forget it.


Murphy struck again, http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2006-12-28,Thu&sel=25#l21

I will do the change from o-r to o+r in the next few days. Any feedback before that?

-- PTh

I have changed the access rights as agreed.

I also took some time to get convinced. And what did convince me was the poor customers that do not run have root access and can just chown the whole tree to Apache.

This is now implemented for the core and all the default plugins. It is in 4.1.0 RC2 and PLEASE TEST it carefully without running a chmod to verify that all is fine.

-- KJL

Changed headline for release note


Fixed permission of 4 files that were missed: tools/geturl.pl, tools/rewriteshbang.pl, tools/tick_twiki.pl, tools/upgrade_emails.pl

-- PTh

I actually did not miss them.

They are command line only tools that are not run by the Apache server so no need to make them world executable.


I still think it is better to leave them as 555. For example, tools/tick_twiki.pl is possibly called by the Apache cgi user via a cron job.

-- PTh

Summary File permissions should be more universally applicable.
ReportedBy TWiki:Main.PeterThoeny
Codebase ~twiki4
SVN Range TWiki-4.1, Tue, 28 Nov 2006, build 12081
AppliesTo Engine
Component BuildScripts
Priority Normal
CurrentState Closed

Checkins 12296 12370 12373 12408
TargetRelease minor
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2007-01-16 - JasonHill
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback