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.

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.

KJL

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

Issues:

• 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.

KJL

[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 
        TWiki.

[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 
        ApacheConfigGenerator.
[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 
        store
[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 
        rights.
[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.

KJL

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

KJL

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.

KJL

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