SettingFileAccessRightsLinuxUnix

File Access Rights on Unix and Linux

One of the most common problems people ask about it how to set-up the file access rights in Linux/Unix.

This small topic answers this question by giving you the exact shell commands that sets the access rights correctly for your entire foswiki directory tree.

This topic covers Foswiki 1.0.

The script below does 2 things:

• It changes the owner of the entire directory tree to the user that apache is run as. Apache is normally started as root and then forks out a number of child processes that do all the work. These child processes run as a user with very few priviledges on the system. The name of the user is given by the directives User and Group in httpd.conf. Each distribution has its own idea what this user should be. In Redhat/Fedora/Centos the user name is apache and the group is also apache. SuSE uses wwwrun as the user and www for the group. Other distributions use nobody or www-data.
• It changes the access rights to all the files in the foswiki tree to the same as it is shipped in the tgz. When you upgrade using the Foswiki-VERSION-changed.zip you run into the problem that zip files contain no user rights so the default right are used. The script below takes care of this.

In the script below I assume your Foswiki tree is /var/www/foswiki and the apache user/group is apache.

First we move to the right directory and change ownership

cd /var/www
chown -R apache:apache foswiki
cd foswiki

Make sure your current working directory is the top of the foswiki tree. The next step changes the access rights. You can copy one line at a time or copy the entire next block of text and paste it to a command line.

• The script prints everything it does so expect to see a lot of output. If you do not want that, or if -v is not supported on your platform, simply remove all the -v.

For Foswiki 1.0.X

find . -type d -print -exec chmod -v 755 {} \;
find data -name '*.txt' -type f -exec chmod -v 644 {} \;
find data pub -name '*,v' -type f -exec chmod -v 444 {} \;
find lib -type f -exec chmod -v 444 {} \;
find locale -type f -exec chmod -v 444 {} \;
find pub -type f -exec chmod -v 644 {} \;
find bin -type f -exec chmod -v 555 {} \;
find bin/logos -type f -exec chmod -v 444 {} \;
find templates -type f -exec chmod -v 444 {} \;
find tools -type f -exec chmod -v 555 {} \;
chmod -v 644 lib/LocalSite.cfg
chmod -v 644 data/.htpasswd
chmod -v 644 data/mime.types
chmod -v 644 bin/LocalLib.cfg.txt bin/.htaccess.txt
chmod -v 444 bin/setlib.cfg
chmod -v 444 tools/extender.pl
chmod -v 444 working/tmp/README working/README working/registration_approvals/README
chmod -v 444 working/work_areas/README
chmod -v 660 working/.htaccess
chmod -v 444 AUTHORS COPYING COPYRIGHT index.html INSTALL.html LICENSE pub-htaccess.txt readme.txt
chmod -v 444 robots.txt root-htaccess.txt subdir-htaccess.txt FoswikiHistory.html
chmod -v 444 foswiki_httpd_conf.txt ReleaseNotes01x00.html

---

-- Contributors: KennethLavrsen

This is equally useful for MacOSX

-- SueBlake - 10 Sep 2006

I found that this method doesn't work on my Ubuntu system. I am using a debian package provided by SvenDowideit. Debian has very strict rules about file ownership and directory layout.

In my installation the perl files are owned by root, group root, so permissions need to be 444 so that user www-data can read them. Similar changes (permissions 755, 644, etc.) need to be made for the bin directory, logos, templates, etc.

-- JoeReinhardt - 25 Oct 2006

During installation I followed step by step all the instructions given under the TWikiOnRedHat. One of the steps there is to change the file users and perms by running the above list of commands. When I ran them the "chmod -v 660 lib/LocalSite.cfg" I got a file not found error as in the installation procedure you have not said when this file needs to be created. So I had not created the actual LocalSite.cfg and still had ONLY the LocalSite.cfg.txt file.

-- KaushalCavale - 21 Nov 2006

There is a lib/LocalSite.cfg.txt file in the distribution, it acts as a template file,and you do not really need it. The first time you run configure and save its settings, the lib/LocalSite.cfg is created for you.

-- PeterThoeny - 21 Nov 2006

The default file permissions are too strict and fail on all but shared hosted sites with suExec, which is not a typical server environment for the target users of TWiki. See suggested change in Bugs:Item3280.

-- PeterThoeny - 12 Dec 2006

We will extend this supplemental document with several examples of access rights for different Unix/Linux environments. From 4.1 INSTALL.html will point to this topic which will either be an index page or an advanced script like the ApacheConfigGenerator where you enter a set of requirements and get the right script.

-- KennethLavrsen - 18 Dec 2006

For the script, I would not distinguish between TWiki versions (the 440 is just of historical value). Better to distinguish standard Linux install on dedicated server, shared host install without suexec, shared host install with suexec, etc.

-- PeterThoeny - 30 Dec 2006

If you are running on an hosted machine using suExec like DreamHost you need to have access rights for other set to the same as user in that example. So typically replace the 0 with the user value.

So for instance you get:
find data -name '*.txt' -type f -exec chmod -v 666 {} \;
Instead of:
find data -name '*.txt' -type f -exec chmod -v 660 {} \;

-- StephaneLenclud - 11 Jan 2007

Shall we add that script to the root of the release distribution and call it something like fixaccessright.sh?

-- StephaneLenclud - 12 Jan 2007

The 4.1 settings seem to be working great. I have adjusted above 4.0 script to set same access rights as we decided for 4.1. The reason there is still a 4.0 script is that the directories and files have changed a little between 4.0 and 4.1 and it may be confusing to get file not found warnings.

The reason for not putting a script in the root are two. 1. The directory structure is not always exactly as distributed. 2. I know some put the entire twiki directory in a place where things are executable and I do not like to have a chmod script being executable from a browser even if it normally would be harmless.

-- KennethLavrsen - 15 Jan 2007

I am on a 1and1 shared host using Debian. It has a user of "www" and group of "www". I cannot chown (probably because I am not the superuser). I can chgrp, but only to a group I am a member of, and I don't seem to be in the same group as "www". So the end result is I can change permissions, but not ownership.

This has given me some problems. I have been able to fix them by granting read permissions to "others", but I am not sure if that is secure.

-- EricWoods - 07 Feb 2007

Also, I found your description of what is happening ("forks out a number of child processes" etc) very helpful. However, I have one question: .htpasswd only lets owner write to it, but for me, needs read access for owner, group and everyone. Therefore, these child processes don't seem to be classified as 'owners', yet somehow the file can have new TWiki users written to it. If it is not a child process writing to .htpasswd, what is?

-- EricWoods - 07 Feb 2007

On the TWikiVMDebianStable Linux / Twiki Image the command on the top of this page would be:

cd /home/httpd
chown -R www-data twiki
cd twiki

-- WilliamKahler - 22 Mar 2007

The following two commands didn't execute because the files were not present, but may be they will appear after I install. I am using Ver 4.1.2:

chmod -v 644 lib/LocalSite.cfg chmod -v 644 data/.htpasswd

-- VenkataGanti - 28 Jul 2007

the commands doesnt work on my Busybox.

chmod: invalid mode: -v

-- ThomasHesse - 01 Nov 2007

Sorry, i don't see: The script prints everything it does so expect to see a lot of output. If you do not want that remove all the -v.

-- ThomasHesse - 01 Nov 2007

I used -R on my BusyBox v1.1.0 instead of -v that seems to work. Guess I could have removed -v, hm maybe -v should be removed from the script in order to make it more compatible.

-- FranzJosefGigler - 01 Nov 2007

Isn't there a

 '*.pm' 

missing in 4.2.x

find lib -name -type f -exec chmod -v 444 {} \;

line?

-- MarcoPoli - 02 Nov 2007

Seems like. Since this is a wiki you can make the change!

-- PeterThoeny - 02 Nov 2007

No the 4.2 script is correct. There are now a couple of non .pm files that also need protection as 444. So first I set all to 444. And then I loosen up lib/LocalSite.cfg to 644

-- KennethLavrsen - 06 Nov 2007

Then use '*.*' as parameter as I had to do on my BusyBox to get it going. It seems that some chmod versions don't support the -v parameter, so why not drop it or use -R instead?

-- FranzJosefGigler - 06 Nov 2007

The use of chmod with -R is usually a bad idea since you need execute right for directories, but don't want it for files. Regarding . I'd think that the correct solution is to drop the -name parameter. It isn't needed, but if it is given, it requires a name expression. I'll fix that.

-- HaraldJoerg - 06 Nov 2007

Thanks for the explanation. Would it be bad to drop the -v parameter as well, it is not needed either, right?

-- FranzJosefGigler - 06 Nov 2007

Correct, -v is not needed for the commands to work. It is short for --verbose and prints what it is doing. According to http://www.busybox.net/downloads/BusyBox.html both its chmod and chown commands support -v. So, I'd prefer not to remove it, and rather add a comment about its purpose.

-- HaraldJoerg - 06 Nov 2007

There seems to be an error in these scripts, as otherwise I believe there is no point in having pub in the 3rd line since the 6th line changes permissions for all files in pub. Or should the order of these two lines be changed?

-- DanielBiren - 23 Feb 2008

Yes there is some errors. How about this then. First do the general, then the particular:

#!/bin/sh

TWIKI=/usr/local/mytwiki

find $TWIKI       -type d -exec chmod -v 755 '{}' \;
find $TWIKI       -type f -exec chmod -v 444 '{}' \;
find $TWIKI/data  -type f -exec chmod u+w '{}' \;
find $TWIKI/pub   -type f -exec chmod u+w '{}' \;
find $TWIKI/bin   -type f -exec chmod -v a+x {} \;
find $TWIKI/tools -type f -exec chmod -v a+x {} \;

chmod -v u+w $TWIKI/lib/LocalSite.cfg
chmod -v u+w $TWIKI/data/.htpasswd
chmod -v u+w $TWIKI/data/mime.types
chmod -v u+w $TWIKI/bin/LocalLib.cfg.txt bin/.htaccess.txt
chmod -v u=rw,g=rw,o= $TWIKI/working/.htaccess

28 Apr 2009 - 01:22:29 - StephaneLenclud

I have been using for years a convention that I suggest we adopt. As there is no one-size-fits-all script, let's distribute many examples of these "fix permissions" script, and ask the user to put one named as FIX_PERMS at the root of the Foswiki install. This way, when I go on any of my installs, I know I can just run this script after any manual operation on the files, it will do the right thing for the right install, calling sudo for this if needed, or even calling a CGI script by wget at the installations where I am not allowed to sudo (but where I can make the web server execute cgi script to do some chmods on its files). And my automated maintenance scripts can also call this script if needed.

-- ColasNahaboo - 28 Apr 2009

Just a quick note that that last script write protects all of the cgisession files in working/tmp. They need to be writable by the web server.

-- GeorgeClark - 12 Apr 2010

5 years of life of this topic and we still don't have a debugged consensus yet. Couldn't this be an almost release blocker, and get this put to bed? This is in the Support web after all. As an end user I'd like to see whole topic re-factored, with the out of date trimmed or at least twisty'd. The optics are really bad when the developers don't seem to have consensus (or aren't sufficiently inclined to share de rigeure with those that need it most). A bunch of users not getting this right and getting their site abused could give the project a black eye. To be honest I'd prefer to see this as one of the warnings in Config if not set right.

-- CraigBowers - 12 Apr 2010

Agree. It would definitely be nice for configure to do this. Note that the Extension installers use the manifest to automatically set the permissions of every installed file per the manifest. I included a function to set the permissions as well, but it's not used because the install sets each file's attributes after the copy. (If I could pass the core manifest to Package.pm, it could already do the updates). We are past feature freeze for 1.1, but it sounds like a good 2.0 project - file/directory permission checks.

-- GeorgeClark - 13 Apr 2010

Besides ordinary permissions, there's selinux, which is enabled by default (a good thing) on fedora. It makes even installing a plugin, much less doing an install or upgrade rather painful, as getting the context assignments and local policy adjustments sorted out can be quite a project.

We need to think about how to integrate selinux support so that the right things happen when installed on a selinux system. This is partly having a directory structure that doesn't mix read-only with read-write content (so security context inheritance does most of the work); partly a policy package; and partly documentation. And probably some installer support.

Right now (at least for me), it's an experience-based, iterative process that takes too much maintenance. It needs to be reduced to a recipe and automated...

-- TimotheLitt - 02 Oct 2010

Here is a script that I've used recently:

#!/bin/sh

echo "All directories have exec bit for recursive reading"
find . -type d  -exec chmod -c 755 {} \;

echo "Everything in root is read only"
find . -maxdepth 1 -type f  -exec chmod -c 444 {} \;

echo "Files in data & pub writable by server, except for rcs files which are read-only"
find data -name '*.txt' -type f -exec chmod -c 644 {} \;
find pub -type f -exec chmod -c 644 {} \;
find data pub -name '*,v' -type f -exec chmod -c 444 {} \;

echo "Everything in data is writable by server."
find data -maxdepth 1 -type f  -exec chmod -c 644 {} \;

echo "bin and tools needs to be executable - with exceptions"
find bin -type f -exec chmod -c 555 {} \;
chmod -c 644 bin/LocalLib.cfg.txt bin/.htaccess.txt
chmod -c 444 bin/setlib.cfg
find tools -type f -exec chmod -c 555 {} \;
chmod -c 444 tools/extender.pl

echo "Everything else is read only"
find lib -type f -exec chmod -c 444 {} \;
find locale -type f -exec chmod -c 444 {} \;
find bin/logos -type f -exec chmod -c 444 {} \;
find templates -type f -exec chmod -c 444 {} \;

echo "Working is server writable - with exceptions"
find working -type f -exec chmod -c 644 {} \;
find working/configure -type f -exec chmod -c 444 {} \;
chmod -c 444 working/tmp/README working/README working/registration_approvals/README
chmod -c 444 working/work_areas/README

echo "Restrict security related files should not be world readable."
find . -name .htaccess -exec chmod 440 {} \;
chmod -c 640 data/.htpasswd
chmod -c 640 lib/LocalSite.cfg

• Configure complains if working/configure files are set to 444. Better to have them 644. -- ArthurClemens - 02 May 2012

  ---

What is chmod -c?
That's not an option I have in my version.

... ah. Found it here: http://www.computerhope.com/unix/uchmod.htm
=-c, --changeslike verbose but report only when a change is made=

-- VickiBrown - 21 Jan 2012

Looks like a script part is missing on the page.

"You can copy one line at a time or copy the entire next block of text and paste it to a command line." After that comes a section "For Foswiki 1.0.X".

-- ArthurClemens - 02 May 2012

Going back to the early revisions of this topic, the "For ... version" block was several versions. And the "copy the entire next block" was referring to the version specific blocks. So nothing is missing, it's telling you to copy/paste the verbatim block in the "For Foswiki 1.0.X" section. And nobody has ever added a block for Foswiki 1.1. Really this whole topic needs refactoring very badly.

-- GeorgeClark - 02 May 2012