A desperate story about file permissions and ownership

[Oliver]

Sorry, I know of course nobody likes this kind of question. But I'm doing my best to provide you with any information to help you help me.

First I installed CMS Made Simple 1.0.2. Everything looked fine. Then I tried to install modules. With the module manager I just got:

Code: Select all

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 317440 bytes) in 
/home/www/web296/html/modules/nuSOAP/classes/nusoap.php on line 809

O.k., I can install modules by ftp. This works. I go to Extensions > Modules and there - strange enough - I can not only install the newly uploaded module. Under the heading "Action" I can also "Change Permissions". If I give this link a try,  I get an error:

Code: Select all

Couldn't change permissions on some files (Troubleshooting)

I was though not too much worried about this as the modules nevertheless worked fine. That is, until I tried to get MySQL Dump working. After installation I was prompted to

Code: Select all

check and save the path to mysql binaries before using Mysql Dump.

I tried the usual suspects like "/usr/bin" and "/usr/local/bin". But none of these worked. So I emailed my provider and asked. I was told this is the path:

Code: Select all

/usr/local/mysql/bin

It didn't work. Still the same error message. So I thought, maybe this guy doesn't know what he's talking to me and I decided to look after by myself. I  installed SystemInfo - a module that just tells you everything about your system. But not about the path to the binaries. So in case you need to know more of this stuff to solve my problem, I can give you all the details.

My next step was to look into the config.php. I installed Config GUI, another nice module that lets you edit your config file with a nice interface. So this was when I got another error that confused me:

Code: Select all

Config.php is not writable by PHP 

I tried to change permission. The only thing that got Config GUI running was "777". For obvious (security) reasons that's  not exactly what I want.

So my last step took me to look up ownership of the files. 99% of the files are owned by "web296" - thats me when I upload things like a config.php by ftp. Some exceptions like images uploaded by the Image Manager are owned by "wwwrun" however.

So here I am at my wits' end. What's going on on this install? Does this sound familiar to anybody who has NOT given up and changed hosting?

Your help is highly appreciated!

Desperately

Oliver

[calguy1000]

Here's a very quick lesson in unix file permissions, etc.

In your example: wwwrun is (most likely) the user that is executing the httpd process (probably apache).  You're account is web296.

Unix permissions are of the (abbreviated form).  and are usually expressed in octal

  rwxrwxrwx
    ^  ^  ^
    |  |  \
    |  \  other
    \  group
    owner

This describes a chain of permissions.  So a permission of 765 (for example) on files, would translate to binary in:  111 110 101 or (read+write+execute for owner, read+write for group, read+execute for other).  Group means any person belonging to the same group that this file is owned by. All files have two owners, a user, and a group owner.

Now, in order to see the contents of a directory, the user must have (somewhere in the chain) 'execute' permission on the directory.  In order to read the files you need read permission somewhere in the chain, and the samee for write permission.  Write permission is needed on a directory (somewhere in the chain) to create files in a directory.

When files are created, the initial permission on the file depends on the "umask" or the 'file creation mask' as we've titled it in the site preferences.  The umask is a binary mask (usually expressed in octal) that is 'bitwise xor'd' with 777 (111 111 111) to determine a files initial permissions.  Usually, the default umask is 022 (on most systems with login abilities) which means that new files would be created as follows:

    111 111 111
xor 111 010 010
    ------------------
    111 101 101  (755) or (read+write+execute for owner, read+execute for group, read+execute for other).

The user that is running the program that creates the files will be the initial owner, and (usually) that user's default, or active group will be the initial group owner on the file.  One caveat to this, is that new files are not usually given the execute bit by default (though directories usually are).

When you upload files via ftp as user web296 then the permission on the files will be dependant upon that user's umask, and the owner will be web296, and the group owner will be whatever user web296's default group is set to.

Similarly, when files are created by wwwrun, (either by uploading an XML file, or an image, or by generating thumbnails, or mysqldump, etc), the owner of the file will be wwwrun, the group will be whatever wwwrun's default group is, and the permissions will be determined by the umask in the site preferences.

So,  your problem probably is that your umask is set to a value in the site preferences that don't give new directories the execute bit for the 'other' users, and/or the read/write bits.  a umask such as 077 would do this.

There is no real fix for this problem, and permissions will be a constant issue.  Here are some of the things that you can do to help though:
a) Hack/Modify the ChangePermissions script I have attached to open up each of the directories you want opened appropriately (this usually
    involves changing the modules directory (and everything below it) to 777, as well as maybe the uploads directory.
b) Go in and manually change the file creation mask to '000' which (should) allow all newly created files to be created with permission so that
    you can see them when in ftp, and read/write them as well.

In future releases, I hope to make some modifications to module manager to better illustrate the permissons that will be given to newly created files.  I'm just not there yet.

I'm gonna mark this topic as sticky...  it seems to get asked quite a bit.

[Kuuke]

Maybe it's me but the attached file seems to be empty?

By the way I encounter the same problem so I want to try your "solution".

[jaap]

When I set the value for the umask in the admin panel to 000 then newly installed modules' directories (in the modules directory) get permission (drwx.rwx.rwx) and files get -rwx.rw-.rw-

When I set this value to 022 it results in (drwx.r-x.--x) for directories. I cannot see the files.

This looks as if the umask value 022 as entered in the admin panel is not interpreted as octal but as decimal

So, to test this, I changed the value for the umask in the admin panel to 018 and as a result I got drwx.r-x.r-x permission for directories and -rw-.r--.r-- for files.

Conclusion: if you want 022 (octal) as umask, you need to type 018 in the admin panel.

[roundtrip]

When I set the value for the umask in the admin panel to 000 then newly installed modules' directories (in the modules directory) get permission (drwx.rwx.rwx) and files get -rwx.rw-.rw-

When I set this value to 022 it results in (drwx.r-x.--x) for directories. I cannot see the files.

This looks as if the umask value 022 as entered in the admin panel is not interpreted as octal but as decimal

So, to test this, I changed the value for the umask in the admin panel to 018 and as a result I got drwx.r-x.r-x permission for directories and -rw-.r--.r-- for files.

Conclusion: if you want 022 (octal) as umask, you need to type 018 in the admin panel.

Same problems for me on a shared LAMP solution. Changing the umask to 018 seemed to fix the issue of directory and file browising.

Can someone with more knowledge of Linux and CMS MS comment on what is going on with the default 022 permissions and why it has been set-up like that when it is giving some users problems.

Also, it would appear that any additional module gets installed by the web server account which means people on shared hosts can't do anything to them. That is a pain. I suppose we could ask our web host to change the ownership but they will find that a pain. Is there anyway to easily get around this?

Thanks.

[fehumm]

Wow. You reply very quickly -- respect to the community!

My problem is solved.
I got my own little apache on a LAN server here and "chown'd" all the files to my local user. Changing them back to www-data did the trick. Thanks!
Unfortunately I can not modify these files from my remote machine any more, so I have to change the group to e.g. users.
When CMSMS writes files, it writes them as www-data with the group www-data. Is it possible to specify the group they are created with (i.e. user: www-data group: users)?
Didn't the sticky bit provide this feature (or was it just for same permissions)?

Oh, I almost forgot: Thanks for your help!

[Gregor]

A work around that helped me, I asked the 'root' to create an event (I can not remember the correct Unix name) that sets the permission to the correct user. This events (chown) runs every 3 minutes. Well, you can discuss about the interval, however this works fine for me.

G

[CMSMS-Fan]

The problem for people like myself and the greater majority of us out here is that we never get root privileges on our hosted servers and as pointed out you can FTP stuff to your site and the owner is your FTP user name but when CMS or any PHP system creates a file on the fly the owner is the server.  In my case that is always Apache.
The solution I found is a file called Webadmin.php (Written by Daniel Wacker but can't even remember where I found it) but it works very well and as it is PHP you can change anything on your site as when you run the php you are running it as the root account as php is running as root - but as a word of warning make sure you don't leave the file in a public access area or anyone finding it can do the same to your site.
Take the file below and change the file extension from .txt to .php.  Save it as whatever.php and upload it to your site.  then hit it with your browser www.whatever.com/whatever.php and you will be able to CHMOD create, edit, delete, move etc files on the site.  It is very simple to use but very dangerous to as once done it is done.....  Use it with caution and don't leave it for others to use on your site.
I hope this is useful and can solve some of your permission issues.


[gelöscht durch Administrator]

[calguy1000]

FYI:  PHP is (99.99%) guaranteed not to be running as root (and if you'd like I can prove this).  It's running as the same user as httpd is running as. this will allow you to edit any files owned by the httpd user.  which includes (with respect to CMSMS) any files in the tmp directory, and any files created by uploading files in the image manager, or files created by uploading XML themese or modules.

Here's a brief list of where to start reading to understand unix permissions.
http://www.google.ca/search?q=basic+unix+permissions+ownership+chmod+&start=0&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:en-US:unofficial

[winchester]

Hi,

I'm having this same problem. I'm not sure, but after installing a few modules I get a message on the site pages like below:

We are currently experiencing technical difficulties. We will try to fix the problem as soon as possible. Sorry for the inconvenience.

I first came across this with the first installation and decided to start over (since is was a very new site) only I had to ask my host to assist in deleting some of the folders. I suspected that CMSMS was creating the new module folder (and other folders) as a different user and group.

I wanted to try the work-around posted by calguy1000, but the attachment in his post is empty. I downloaded and installed the webadmin.txt script to give it a try and just as I suspected, some of the folder are owned by httpd and assigned to httpd ground.

The only problem now is how can I use this webadmin script to set these folders and files to a new owner and group without the my host assistance?

[CMSMS-Fan]

Winchester, unfortunately you can't use the script to change ownership.  However, you can CMOD the files and even delete them.  You can then replace them using FTP or re-create the file using the Webadmin PHP script so the owner would be either your FTP account or Apache dependent on what you wanted the file for and how your server is configured.

[Ned Nowotny]

Is it possible that the following bug is responsible for the problems being described in this thread?

    [#1653] Calls to umask are incorrect and result in incorrect file permissions.

I was having a problem with file permissions on generated thumbnail images until I made the fix suggested at the end of my bug report.

[calguy1000]

Yes, this is possible and we'll attempt to address it for the 1.1.1 release.

[openmtl]

.....
I hope this is useful and can solve some of your permission issues.

Thanks for that webadmin script. I've never really looked at it too much so far but just discovered when I did ".." that I can wander EVERYWHERE on my hosting companies Web server !. My trick of hiding the CMSMS install directories with unlikely to be guessed names just blown out the door.

The script has allowed me to delete modules installed via CMSMS which get user/group ownership of the web server and not my FTP account.

I'm now off to look for where I've left passwords and junk on my web site over past 3 years.

[Nullig]

It could be a memory problem. What is your memory_limit set to? Try increasing it to 16M or greater.

Nullig