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) |
pub/TWiki/WabiSabi/ wabisabi.gif |
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.
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