Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 2 down vote favorite

A friend of mine hosts some of the websites he has built for his clients. Somehow he messed up the permissions giving all clients' websites a 403 error upon loading.

When I ssh to his server and log in with my account (I have 2 websites running on his server too), the first message I get is:

Last login: Tue Jan 24 11:54:37 2012 from 82.168.36.207 Could not chdir to home directory /home/michiel: Permission denied -bash: /home/michiel/.bash_profile: Permission denied

I then sudo and chdir to /home/. I (recursively) chowned the folder michiel to michiel:michiel and chmodded it (recursively) to 755.

I still get the same error at login and the website still gives me a 403 error.

I have tried to figure out if SELinux is causing problems, but "find selinux" outputs that there is no such file or folder.

Any ideas on how to solve this problem?

share|improve this question
Output from sestatus? Is de web-content in your home-folder? Is /var/www/myuser/ or something alike mounted to your homedrive? Are there errors in /var/log/httpd/* ? – Bart De Vos Jan 24 '12 at 11:56
bash: sestatus: command not found. The sites are all in /home/user/public_html/. – Chielt Jan 24 '12 at 12:02
@BartDeVos Vos In /var/log/httpd/error_log I get a few errors saying: [Tue Jan 24 12:41:56 2012] [crit] [client 119.63.196.80] (13)Permission denied: /home/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable. Other error logs don't have much info. – Chielt Jan 24 '12 at 12:09
sestatus is normally on root's PATH, but not regular users', though it doesn't need privilege to run. Try /usr/sbin/sestatus. – MadHatter Jan 24 '12 at 12:22
@MadHatter, there is no sestatus in /usr/sbin/ – Chielt Jan 24 '12 at 12:34
show 3 more comments

2 Answers

up vote 2 down vote accepted

From comments, it looks like the permissions on /home do not have the execute bit set:

drw-r--r-- 26 root root 4.0K Jan 24 03:17 home

You need the execute bit set in order to enter a directory. So, "chmod a+x /home".

The trick is that your friend may have blown up the execute bit recursively on all subdirectories. If there aren't that many users, I may just go to each home directory and verify the permissions by sight. If there are a lot of users, there are ways to run the chmod more efficiently, maybe something like:

chmod -R a+x /home/*/public_html

Use caution (unlike your friend!)

share|improve this answer
Thanx, up and running :) And yes, my friend did not use caution. He usually manages his server with DirectAdmin. When I asked what happened, he said he didn't understand what -R did untill he executed a command using it. Guess he learnt the hard way :) – Chielt Jan 24 '12 at 14:22
Well, at least he wasn't playing around with the "-r" in "rm"! – cjc Jan 24 '12 at 15:00
3  
Consider a+X instead of a+x. The capital X will cause chmod to only add the execute bit to directories and to files that are already executable for some users. This should avoid applying the execute bit to files that have no business being executable (e.g. text files). – James Sneeringer Jan 24 '12 at 15:43
@JamesSneeringer heh, when did they add "X" into the chmod options? That's a reminder to occasionally read through docs for options you've forgotten/didn't know about. That said, I'm not sure if that would have helped, since the execute bit was removed entirely on the errant command. – cjc Jan 24 '12 at 15:52
It's more to avoid adding it to files that don't need it. You're right that it doesn't help if you need a particular file to be executable. Still, I prefer +X, or a targeted find command (as in Luis's answer), but that's just me. – James Sneeringer Jan 24 '12 at 16:16
up vote 1 down vote

The first command gives other users than the owner or her group the permission to enter the directory (hattip @cjc). The second give read permissions to the files:

find "/path" -type d | xargs chmod o+x
find "/path" -type f | xargs chmod o+r

This is the minimal set of permissions for files to be published. If anyone was relying on DirectoryIndex, the directories will need o+rx instead of just o+x.

My usual set of permissions is:

$ ls -ld /var/www/me.example.com
drwx-----x 12 me-example-com users 4096 Oct  4 16:44 /var/www/me.example.com

$ id me-example-com
uid=1000(me-example-com) gid=100(users)

This trick I learned on the web means that other members of group users won't be able to look into each other's files, but by default the rest of the system will let www-data (the user Apache runs under on Debian) to enter the directory.

share|improve this answer
1  
In this setup, a user's document root is /home/user/domains/example.com/public_html. What I usually do in /home is chown $user:$user /home/$user, chmod 755 -R /home/$user , find "/home" -type f | xargs chmod 0664. Somehow the owner of the server managed to chmod /home/ denying access to the underlying files. – Chielt Jan 24 '12 at 14:18
Can I login or use FTP to goto someone else's /home/$anotheruser? I'm trying to avoid that, although in my case I'm the one who uploads the sites... Still, it seemed to be a good way to limit breaches. – Luis Bruno Jan 24 '12 at 19:06
if you set the ownerships right, a user will not have this possibility. You would, when logged in as root user. – Chielt Jan 25 '12 at 19:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.