Imagine a server setup of a shared webhosting company where multiple (~100) customers have shell access to a single server.

A lot of web "software" recommends to chmod files 0777. I'm nervous about our customers unwisely following these tutorials, opening up their files to our other customers. (I'm certainly not using cmod 0777 needlessly myself!) Is there a method to make sure that customers can only access their own files and prevent them from accessing world readable files from other users?

I looked into AppArmor, but that is very tightly coupled to a process, which seems to fail in that environment.

  • 12
    I would actually consider whether the recommendations of the "web software" to chmod files 0777 is strictly necessary, i.e. address the root cause of the problem, rather than the symptom that, by doing so, anyone can read anyone else's files. Many times the allow all access recommendation is simply a cheap way of avoiding support calls, or lack of technical prowess in being able to set permissions up correctly. In almost no cases have I had to set files 0777 or grant applications full root access when requested. Education of the users and/or vendors helps massively here. Jul 11, 2014 at 12:16
  • 3
    @CosmicOssifrage, users can't be educated that easily, they don't want to read instructions or manuals. Jul 11, 2014 at 12:45
  • 12
    Any "web software" that still recommends 777 permissions needs to be taken out and shot. Use suexec or mpm_itk or similar. Jul 11, 2014 at 15:27
  • 3
    @CosmicOssifrage I don't think Phillipp is telling or forcing users to chmod 0777 their files. I think he's nervous about them going to loltoturialz.com/php_problems and setting chmod 0777 on their own while blindly following a poorly written article. There's really no way to prevent them from doing so, or to prevent them from being upset when someone steals their stuff.
    – Kevin
    Jul 11, 2014 at 22:23
  • 2
    @kevin - which is precisely why warranty void was created. I have almost never seen a serious appliance (be it software compiled, a bunch of scripts or whatever) without such a clause. And believe it or not - in most corpprate environments users are well aware of this
    – Dani_l
    Jul 12, 2014 at 5:55

8 Answers 8


Put a restricted and immutable directory between the outside world and the protected files, e.g.

 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

or /home/joe/restricted/public_html.

Restricted means that only the user and perhaps the web server can read it (e.g. modes 0700/0750 or some ACLs).

Immutability can be done with chattr +i or by changing the ownership to something like root:joe.

An easy way to create that hierarchy on Ubuntu would be to edit /etc/adduser.conf and set GROUPHOMES to yes.


There is an option which you might want to consider (depending how much work you want to do for that).

As others already posted, "normally" you cannot prevent someone with shell access to read world-readable files.

However you could chroot them into their own home, basically limiting the shell access to, first, only the root directory you want (AKA the home directory) and, second, prevent the users from executing everything you do not want them to execute.

I did a similiar approach when I had one user to have access to the webfiles, but I did not want to have him seeing other files outside the webfolder.

This did have a lot of overhead, was a mess to setup, and every time I updated something, it broke.

But for today I think you could achieve it pretty easy with the OpenSSH chroot option:

WikiBooks OpenSSH

  • chroot for SFTP is easy to implement, but I'm not sure it's that easy for shell access. You'd have to setup a chroot with all the binaries and libraries for each user. Jul 11, 2014 at 12:30
  • 2
    That's implementation specific. ARCHLINUX has a specific arch-chroot command that takes care of all the extra bind mounts etc wiki.archlinux.org/index.php/Change_Root#Change_root
    – Dani_l
    Jul 11, 2014 at 12:41
  • @CristianCiupitu thats what i did, allowing only a specific subset of commands with linking all nessesary libraries, thats why i said it was a mess :) Dani_l true, my setup was a debian server, i never got the time to check in gentoo sadly. Jul 11, 2014 at 12:49
  • @Dani_l: what about the installed packages? The arch-chroot command doesn't seem to cover that. And then there's also the issue of wasted disk space with all the duplicates. I'm not saying it's impossible to do it, just that it might a bit more complicated currently. Jul 11, 2014 at 13:13
  • 1
    Something to make this a -lot- easier is to use UnionFS to chroot users into a special union of the rootfs in read only mode and a read write home directory, this means they see all the system packages and binaries but writes are automatically done in their home folder. this -must- be coupled with making all of the home directories 700 permissions else users could read files from other users anyway.
    – Vality
    Jul 11, 2014 at 23:31

I have found POSIX Access Control Lists allow as you, as the system administrator, to protect your users from the worst of their own ignorance, by overriding the regular user-group-other file system permission, without much of a chance to break anything crucial.

They can be especially useful if you for instance (f.i.) needed home directories to be world accessible because webcontent needs to be accessible for apache in ~/public_html/. (Although with ACL's you can now do the reverse, remove access for all and use a specific effective ACL for the apache user. )

Yes, a knowledgeable user can remove/override them again, are just uncommon enough that that's unlikely, and those users that can are typically not the ones to conveniently chmod -R 777 ~/ anyway, right?

You need to mount the filesystem with the acl mount option:

 mount -o remount,acl /home

In many distributions the default is to create user groups, each user has their primary group, and I have set all users in a secondary group with the unimaginative name of users.

Using ACL's it is now trivial to prevent other users from accessing the home directories:


 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Now set the effective directory permissions for members of the users group to 0 no read, write or access:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

The + sign denotes the presence of ACL settings there. And the getfacl can confirm that:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1

The group:users:--- show that group effectively having no access right, despite the regular permissions for other being other::rwx

And testing as user1 :

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

A second common solution on shared systems is to have the automounter mount home directories on demand an a server dedicated to shell access. That's far from fool proof, but typically only a handful of users will be logged in concurrently meaning only the home directories of those users are visible and accessible.

  • 5
    What is "f.i."? I wouldn't recommend using acronyms or abbreviations unless they're a classic one like "e.g.", "i.e.", "etc" and perhaps OP. Jul 11, 2014 at 14:13

Linux Containers (LXC) could be the best combination of chroot and separate system.

  1. They are more like an advanced chroot, not virtualization, but you could combine different operating systems in one server.

  2. You can give an user a complete operating system and chroot him there, so when the user logs in, he goes to his container. And you can also limit processor and memory usage there.

Stéphane Graber, the author of LXC, has a nice tutorial to help you get started.

  • You can't really combine different operating systems, because all of them need to use the Linux kernel, but you can use different distributions. Jul 11, 2014 at 14:11
  • 1
    Thanks :) Yes, different linux kernel based operating systems.
    – maniaque
    Jul 11, 2014 at 14:43
  • @CristianCiupitu do you mean the same identical Linux kernel? or do you mean that each container can have a different version of the kernel?
    – agks mehx
    Jul 12, 2014 at 7:53
  • @agksmehx, all the LXC containers share the kernel of the host. Only their applications and libraries are used. So for example if you have a RHEL 7 host with an Ubuntu 14.04 container, the RHEL kernel (3.10.0-123) will be used, while the Ubuntu one (3.13.0-24.46) will not be used; read also this comment from the tutorial. By the way, since the kernels of the containers are not used, it might be a good idea to remove them in order to save some disk space. Jul 12, 2014 at 13:53
  • @CristianCiupitu that's what i thought. it wasn't clear from the answer or comment, so i wanted to clarify.
    – agks mehx
    Jul 12, 2014 at 21:27

For example, if you want user to have access only to his own home directory, you should do:

cd /home
sudo chmod 700 *

Now /home/username is only visible to its owner. To make this the default for all new users, edit /etc/adduser.conf and set DIR_MODE to 0700 instead of the 0755 default.

Of course if you want to alter the default DIR_MODE it depends on your distribution, the one I posted works on Ubuntu.


As @Dani_l correctly mentioned, this answer is correct in making them NOT world readable.

  • They're called "world readable" for a reason. Jul 11, 2014 at 15:03
  • 1
    @DennisNolte Actually, it does help, even if files are world readable, if they are in a directory you have neither read or execute on you cannot read them anyway.
    – Vality
    Jul 11, 2014 at 23:34
  • 1
    @Vality true, removing my comment as it is plainly wrong. Jul 17, 2014 at 9:25

Just to be pedantic - No, there isn't.
@Marek gave a correct answer, but your question is incorrect - you can't prevent anyone from accessing "world readable" files.
Either they are world readable, or they are not. @Marek's answer is correct in making them NOT world readable.

  • 2
    wrong, chroot/jail the user to a subfolder and hes unable to read "normally" world-readable files. Jul 11, 2014 at 12:13
  • 1
    -1 I think you're being needlessly critical of the OP's question. He wants to give his customers a safety net in case they aren't smart about their permissions. But it doesn't look like to me that the OP isn't aware of how Unix file permissions work or basic security principals.
    – Kevin
    Jul 11, 2014 at 22:06
  • Also, you can put the files into a directory inside a 000 permissions directory, then nobody can access them even if the files are world readable.
    – Vality
    Jul 11, 2014 at 23:32
  • nobody? not even root? ;-)
    – Dani_l
    Jul 12, 2014 at 18:46
  • @Kevin agreed that my comment is being critic closely to unnecessary. However Dani_I should not wirte that hes pedandic and the beeing wrong. Not stating that i don't agree with the rest of his answer. Jul 14, 2014 at 7:17

I see no mention of the 'restricted shell' in the answers given so far.

ln /bin/bash /bin/rbash

Set this as their login shell.


If the web server is running as the same user and group for every domain hosted, it is difficult (if not impossible) to make the setup secure.

You want certain files to be accessible to the user as well as the web server, but not to other users. But as soon as the web server can access them, another user could read them by putting a symlink to the file inside their own web site.

If you can get each web site to run as a separate user, then it becomes fairly simple. Each customer will now have two users on the system, one for the web server and one for shell access.

Create a group containing these two users. Now create a directory with that group and user root. That directory should have permissions 750, which means root has full access and group has read and execute access. Inside that directory you can create home directories for each of the two users. This means the user's home directory will no longer have the form /home/username, but rather something with at least one more directory component. This is not a problem, nothing requires home directories to be named according to that specific convention.

Getting web sites running with different user and group may be tricky, if you are using name based vhosts. Should it turn out that you can only make the separation work with IP based vhosts, and you don't have enough IPs for each site, you can host each web site on an IPv6 address and put a reverse proxy for all of them on an IPv4 address.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .