I wanted to know if there is handbook page or just some info as to what the chmod settings should be for the various drupal folders (including files and modules folders)

I tempered with modules and files directory and not sure what the default chmod settings where.

Thank you,

Comments

PurpleEdge’s picture

There is an article in the handbook which shows a shell script that resets the access.

http://drupal.org/node/26635

However, as a Windows user with not much knowledge about Linux, I would appreciate a simpler representation that I could implement with cPanel for instance.

styro’s picture

Note that it might not suit your server configuration as well as it did his. And I'm not actually recommending you go this far myself.

I'm not sure the extra value from locking it down this much is probably outweighed by the admin hassle of locking/unlocking it each time you want to work on it.

Here's a line by line explanation for non unixy people that want to recreate the settings using some other interface:

chmod -R 700 ~/public_html

Change permissions of his web root folder (~/public_html) and all it's subdirectories and files to 700 (or rwx------). 700 means read (4) write (2) and execute (1) (4+2+1 = 7) for the owner, and nothing (0) for group and world (ie everyone else).

The -R means recursive - ie all subdirectories and files.

touch ~/public_html/locked.gz

Create the locked.gz file he talks about.

find ~/public_html -type f |xargs chmod 404

Change permissions of all files (not directories) under public_html to 404 (or r-----r--). 404 is read only for the owner, nothing for the group, and read only for world.

find ~/public_html -name '*.module' -or -name '*.php' -or -name '*.inc' |xargs chmod 400

Finds all files that have module, php, or inc extensions and changes their permissions to 400 (or r--------). 400 is read only for the file owner and no access for anyone else.

find ~/public_html -name '*.xtmpl' -or -name '*.engine' |xargs chmod 400

You could probably guess what this one does :)

find ~/public_html -type d |xargs chmod 101

Finds all subdirectories and changes their permissions to 101 (or --x-----x). 101 means execute (but no read or write) for owner and world but nothing for group.

You might wonder what execute only means? Read permission on a directory lets you list the files in it, while execute permission on a directory lets you access the files by name as long as you have permissions for the file as well. This setting stops people listing the directory while still being able to access files in it and is a kinda unusual thing to do. It is a little bit like the directory traversal permission on NTFS.

find ~/public_html/files -type d |xargs chmod 701

Sets permissions of files subdirectories to 701 (or rwx-----x). 701 is read, write and execute for the owner, nothing for group, and execute only for world.

In Drupal, it is generally only the files directory and subdirectories that the web server needs write access to. In his case the webserver is accessing the files as the same user as the owner of the files, but that might not be the case for you.

On our Debian server, the owner is the user account that uploads the php to the server, and Apache runs as the www-data user. So we set the group to be www-data, and give the group write access to the files directory (eg 770 or similar). On our server any file uploads will be owned by www-data as that was the user that created the files.

chmod 600 ~/public_html/error_log

Change the permissions on the error_log to 600 (or rw-------). 600 is read and write access for the owner, and nothing for everyone else. Restricting the error log is important, but on most servers I've set up the error log isn't stored under the web root.

-

If you are still a bit confused by the unix permissions and chmod numbers and stuff, here's a good article:
http://www.perlfect.com/articles/chmod.shtml

Anyway, most people won't be able to use that script verbatim. They will need to take account of what their web root directory is, which user the web server runs the php as, what their own user is etc.

Generally the minimum permissions required can be described as a) that the web server account can read the drupal source files, and b) that the web server account can write into the 'files' directory.

Hope that helps a bit:)

PurpleEdge’s picture

Wow, thanks for that Styro! ( - yesterday I couldn't spell Linux now I can program it )

I had errors during install where it seemed I needed to give access of 777 to some folders so subfolders could be created, I'll change them now to see if anything breaks - still very much a test site!

One thing has me confused with my current setup - I have a folder called /files/images where the access mode is set to 740 and I can't access the folder or change the access level for it (using cpanel). I am using the Filemanager, Image and Img-assist modules have one of these locked it somehow?

I'm just curious to know what is in there?

styro’s picture

I had errors during install where it seemed I needed to give access of 777 to some folders so subfolders could be created, I'll change them now to see if anything breaks - still very much a test site!

You don't want to be running with anything 777 in production. That would give any other user on the server the ability to change your files.

Ideally your files shouldn't be world accessible at all, but sometimes the way hosters set up a server it can be hard to avoid.

I have the luxury of having complete control over our server - so I may not appreciate all the difflculties faced by those using shared hosting :)

One thing has me confused with my current setup - I have a folder called /files/images where the access mode is set to 740 and I can't access the folder or change the access level for it (using cpanel). I am using the Filemanager, Image and Img-assist modules have one of these locked it somehow?

The file and directory permissions are quite meaningless without knowing what the user and group ownership is. Does cpanel let you see that stuff? And do you know what account the web server runs as? If not sticking a phpinfo() up there should tell you :)

Generally the web site files you upload to the site are owned by the user you logged in as (eg with cpanel). Depending on how the server is set up, this might not be the same user account that the web server uses to access the files.

What the problem is will depend on what you mean by 'locked'. eg is it a) your cpanel login that is locked out of those directories or is it b) Drupal that is locked out?

For a) it is probably due to those files and directories being created by Drupal using the web server account. Because those files and directories are no longer owned by the user you log into cpanel with, you can't change the permissions anymore via cpanel. The only way to alter permissions on those files without asking the hoster to do it for you would probably be to write a PHP page to do it. The PHP page will run with the same credentials as Drupal does so will be able to alter files that Drupal has created.

If it is b) The fact that Drupal is 'locked out' of that directory (eg no read access at all - the big fat 0) indicates to me that the user account the web server runs as isn't the owner of the directory and isn't a member of the group that owns the directory. If you could get a directory listing but not able access any files that would indicate the read only (the 4) permission is taking effect and the web server account is in the group ownership.

I hope that clarifies things a little :)

PurpleEdge’s picture

740 means user read, write and execute, and group read.

It must be locked by Drupal, because I can't access it with cpanel or my ftp client, but Drupal is using it to save uploaded images - I believe [g] that's why I want to see what is in there.

I didn't realise that Drupal somehow had its own web server account - that it has locked me out of!

Thanks again.

UserFriendly’s picture

You can work around this problem with the (first) code example in this post:

http://drupal.org/node/17212

Copy it into a .php file, change it to the correct directory and the desired permissions, then upload it and navigate to it in your browser.

To prevent the problem happening, create the folders before drupal gets a chance to.

Richard

PurpleEdge’s picture

When I installed Drupal, and the modules for Image, Img-Assist, Filemanager etc I created the folders beforehand but when I tried to configure the "Files" folder, for instance, in Drupal I got the "Access Denied could not create folder" error - even though the folder already existed, Drupal wanted to create it? (I see someone else is also having problems with this)

I changed the "Files" folder to rwx access for Others and then Drupal didn't complain. (If the access for the Files folder is not set to rwx for others, even now, my images don't display)

Thanks for the heads-up, I'll experiment.

PurpleEdge’s picture

Thanks, that fixed it, now both Drupal and I have access to the folder!

styro’s picture

It must be locked by Drupal, because I can't access it with cpanel or my ftp client, but Drupal is using it to save uploaded images - I believe [g] that's why I want to see what is in there.

From that I take it you can still upload files with Drupal and downloads work etc?

If that's the case, I take it the only real problem is that you can't admin the filesystem any more?

I didn't realise that Drupal somehow had its own web server account - that it has locked me out of!

It's not so much that Drupal has its own web server account - its more like the web server runs as a certain operating system user account, and it is the web server that is executing the PHP contained in Drupal. That account will generally be different from the account each customer uses to upload and manage their websites.

The script you were looking at was designed for a hosting environment where the web server switched user contexts so that the web apps ran as the same user that owned the files.

That was evident from his quote below:

In my case all files are uid/gid {my username}. Apache is running as 'nobody' but PHP appears to execute as {my username}.

This switching users is generally not the default setup with Apache and PHP though. Some hosters set it up that way, some don't.

Back to your case: One side effect of these two different accounts is that the web server account needs to be able to read the site content files (eg PHP,HTML,CSS etc) you uploaded (which are owned by your user account) or it won't be able to serve up your content or run your PHP. The other side effect is that files that are written to the file system by the web server (ie any PHP code) will be owned by that account and not your user account. With Drupal this generally means anything under the 'files' directory.

Because all the stuff in that directory is created with 740 perms and you don't own it, your user account won't be able to read it.

If the host won't help you out (and some can be reluctant to lower restrictions like this), you'll have to do it yourself.

As a solution you could upload a PHP script that reset the permissions on those directories and load its url in your browser to run it. That script would run as the web server account, and be able to change permissions on files it owned. Changing permissions to 755 for directories and 644 for files should make them visible to you (and maybe others). Note that other user accounts on the server might be able to read them, but shouldn't be able to alter them.

See http://www.php.net/manual/en/function.chmod.php for some ideas.

Could could even have two scripts - one to lock it and one to unlock it. You'd have to be careful to restrict who could run them though.

I bet you now know more about web servers and unix permissions than you ever wanted to :)

PurpleEdge’s picture

I've been a Drupal user for about a week and have to say that the support here is fantastic.

This is my first install of Drupal, and I am using a test site, and host. I'll be installing a live version on a different host, so I guess I am gaining a lot of experience and hopefully that might cover all the bases [g]

And yes, I have learned a lot and it is _starting_ to make sense?

ronline’s picture

We can fix, at the same time, the htaccess permissions as well =>
find ~/public_html/ -name "*.htaccess" -type f -exec chmod 644 {} \;

venkat-rk’s picture

This is becoming a very useful thread for learning about file permissions etc.

Styro, thank you for the explanations in simple language about UNIX and the intricacies in server set up on shared hosting system. I appreciate your effort because I am on shared hosting and I have seen posts on these forums relating to image and other modules that have tripped people up because of the permissions brouhaha.

Thanks!

styro’s picture

The reason this stuff is such a problem to support is because

a) it's nothing really to do with Drupal itself - just a side effect of the way most hosting is set up.

b) each hosting provider does things slightly differently, so there is no set of steps for solving these issues.

c) fixing it generally requires imparting some lower level unix and Apache skills onto people who haven't really had any exposure to it before. And some (not in this thread of course) are even hostile to the idea of having to learn about this stuff.

d) and as you can see it does take a fair amount of effort to walk through this stuff, and some more experienced Drupal users could be forgiven for thinking its really an issue between the user and their host rather than between the user and Drupal.

How much support someone gets on a topic like this really depends on the attitude of the user and their willingness to learn - in this case PurpleEdge made it much easier to go to the trouble :)

Anyway, if someone else wants to distill this thread down for a handbook page - feel free. Because I don't use shared hosting, I don't really hit many of the issues.

johnnybejohnny’s picture

so good Styro. It really helps.

ajwwong’s picture

and also chown....

Good luck everyone!

http://www.civicspacelabs.org/home/node/8771

Albert
www.ithou.org

geme4472’s picture

Yet another question for this thread... (from one of the unix challenged)

I'm running a dedicated box but using cpanel for admin, so Apache runs as "nobody". Files are owned by the linux user accounts, excepting those the drupal uploads or creates ("nobody"). Because of this setup I have to give "world" read perms on lots of files. However, if I were to chown or chgrp everything to "nobody" and change all perms accordingly so that browser could operate correctly, I'd end in the exact same situation that I started in--apache/browser has the exact same rights as before. However, I've heard people say that it is "bad" to have "world" r/rw on stuff in the public_html directory.

What would I gain by changing things such that world has no perms? What constitutes "bad"? Most importantly, what it is the downside if I leave perms as such...

chmod -R 750 ~/public_html
find ~/public_html -type f |xargs chmod 404
find ~/public_html -type d |xargs chmod 705

And thanks to all for the juicy stuff in this thread.

styro’s picture

Are you running a server for clients? How many different (untrusted) people can upload to it?

Is this server running any other publicly available (non Apache) services? If it is then using group permissions instead of world will still protect your sites from problems in those other services. Or course this is a good reason not to run any services as nobody, but as different dedicated accounts (eg on Debian, Apache runs as www-data).

If there are no other users and no other services - then it doesn't really matter too much whether you use group or world permissions.

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

geme4472’s picture

THANK YOU. I spent a couple hours yesterday trying to get one of our admins to say as much to me, but for some reason those guys are all smoke and mirrors.

Here's the skinny:

  1. We are indeed serving clients and those clients may have sensitive data (though not CC info or anything of that nature)
  2. the server is running ONLY drupal sites. I've removed our marketing website and other ancillary apps and have thrown them onto an el-cheapo hosted server.
  3. I am the only dev who has server access. The admins also do, but have to ask me for pwds.
  4. No one non-IT gets FTP
  5. The server does not run any non-apache services, if I understand what you mean. And since I'm not sure, let me explain. The only user accounts on the server are our web accounts. We are not running anything "outside" of apache, excepting the various servers in support thereof (IMAP, POP, MySQL, OpenSSH, BIND, PureFTPd, etc.). We've talked about running one of the various Open Source helpdesk apps though... is that what you mean?

Thanks for your extraordinary patience as well as for clearing this up for me.

[Edit] I thought of another dumb question... when apache runs as 99 (nobody), is that the same uid that would be given another app that isn't given an explicit uid? If that's the case, this suddenly seems baddish, right? (thanks again)

styro’s picture

IMAP, POP, MySQL, OpenSSH, BIND, PureFTPd, etc.

That sounds like plenty of other services to worry about - you'd need to make sure they are secured properly. Also if any of those services are configured so that users log into them using system accounts (rather than their own internal account databases) you have to also worry about that too.

Ideally a Drupal server would just need Apache, MySQL (listening on localhost only) and OpenSSH (properly secured and firewalled off to just your IP addresses). I'd make sure those other services and Apache all run under dedicated accounts if possible.

I thought of another dumb question... when apache runs as 99 (nobody), is that the same uid that would be given another app that isn't given an explicit uid? If that's the case, this suddenly seems baddish, right?

Sort of, it would depend on the behaviour of the app in question - but if you give nobody access to anything, anything else running as nobody can also access it. The nobody account is a bit of a historical thing that seems to be falling out of favour. These days it is generally better to give each application its own account.

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

geme4472’s picture

Wow, I think I can actually feel my blood pressure rising. I'm looking into this presently with the company that manages the server.

If this project gets out of hand at any point, would you be interested in consultative work on this topic?

Many, many thanks.

styro’s picture

...they might have good reasons for their permissions set up - talking to them should be enough to sort it out. It's not that running lots of stuff as the same account is insecure by itself - it's just that it has less layers of defence than it could possibly have.

If your server is a dedicated Drupal box though, you probably don't want email and DNS servers running on it. But I don't know the actual requirements for the server so I'm only speaking in general terms.

And, no sorry - I'm not available for consultancy work. There's probably far more qualified people out there anyway :)

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

geme4472’s picture

Excellent ideas, all. It looks like we're going to enable the suexec wrapper, but first we're going to have to procure a dev server (right now I just have dev user accts). So now, my bigger problem is getting management to cough up the cash/resources to make some of this stuff happen. As of Friday my answer was "not until May", which could be worse, I suppose.

THANKS! I sincerely appreciate all the help.

rlilloy’s picture

What happen if I have several fólder with diferente users and different share permissions.

For instance:

User 1

User 2

User 3

Folder 1 sharing 1 -2

Folder 2 sharing 1 -3

Folder 3 sharing 1-2-3

I don’t know how with drupal, I can do it

Danny_Joris’s picture

subscribing

soulston’s picture

subscribing