Loss of file ownership after mod installations

Started by Lou69, December 05, 2010, 07:10:40 PM

Previous topic - Next topic

Lou69

I am at the last straw on this problem.  :)  Every time I install a mod in SMF 2.0 RC3 or RC4, I lose ownership of one or more of the files or folders that were installed. Not really sure if there is a rhyme or reason to the files or folders chosen to loose ownership to. I have had php files and image files, etc that I lost ownership to.

I only loose this ownership in the public_html or www folders after a mod installation, not the /home area. Is there a solution for this problem? 

Antechinus

It's a server config thing. I get the same problem sometimes. Other mods are fine. Hey ho. About all you can do is either get your host to run a chown (if they give good support) or to use a php script to force chmod, after which you will be able to change permissions on the files yourself.

Lou69

Thanks man. The host has been very good about the chown ticktets I send in, but, it is getting old creating those tickets. I am going to have to come up with an alternate solution. A new host or maybe another forum software. Problem is that I really don't know if this loss of ownership is common among all forum software or more so in SMF. Or even if it is more of a host problem.

Something will have to be done, even if I have to go to the hosted plan from IPB. Not what I really want to do, to be honest.

Norv

It's due to the host's server configuration. (how Apache, PHP are set up).
SMF is a PHP script, run by your host's server on behalf of the user set in their configuration. Since you experience loss of ownership of files, that user is not your FTP user, but some default user Apache is running with. Thus the files and folders created by PHP (for example, the files and folders created by SMF running a mod installation) will be owned by that user ("nobody" or "www-data" usually).
Things are different on servers which are configured to run PHP under another user - your user. Then PHP scripts would be able to create files owned by that user too - yourself.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

青山 素子

Quote from: Lou69 on December 05, 2010, 08:11:11 PM
Problem is that I really don't know if this loss of ownership is common among all forum software or more so in SMF. Or even if it is more of a host problem.

The reason you are seeing this "ownership problem" often with SMF is the way SMF handles modification installation. When making changes to a file, it writes a whole new copy of the file. This file is then owned by the creator, which is the user/group PHP runs under. Likwise, any new files a modification adds will also have that ownership. Note that this issue is not specific to SMF, but it's a server configuration issue.

Some hosts use solutions like suExec for security partitioning purposes. On those hosts, PHP will run under your master account, which should be the same as your FTP account. In those types of cases, you won't have any problems. Other hosts use Apache as an internal module, where the webserver runs under a different user than your FTP account. Files created using PHP will then have the "wrong" ownership from the FTP view of things. For those hosts, even using a provided control panel will cause the same problems as it's running under a different user than the FTP user.

There are a few server-side solutions to this issue. The host can use virtual FTP users with the same UID/GID as the webserver accounts and rely on chroot to lock directories down correctly. The host can also use virtual FTP users and use SGID to make any new files owned by the same group as the FTP user. (This is my preferred solution when using mod_php.)

The fact of the matter is that it doesn't matter what forum software (or any web software) you use, this problem stems from the server configuration. Any file uploaded through the website and saved on the server will have this permission issue. It might not be as noticeable with software that doesn't make file modifications, but it's still there. Some hosts just don't have the expertise to know how to get around it or the control panel software they use makes it impossible to handle it easily.


Quote from: Lou69 on December 05, 2010, 08:11:11 PM
Something will have to be done, even if I have to go to the hosted plan from IPB. Not what I really want to do, to be honest.

Well, if you use a hosted service, you'll not have to worry about FTP at all, so the problem will certainly disappear from your sight. That doesn't mean it's still not there, just that you can't see it either way.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Lou69

Norv and Motoko ..

Thank you for those well thought out and excellent answers. For once, I understand what the problem is and what possible solutions are. I don't know that my host would consider the virtual FTP path are not. I could always ask.

The host is always gracious about chown'ing the files, it is just a hassle to make the tickets and as I do most of my work late at night, it is a pain to stop and then pick back up the next night. What bothers me is that I can install an Ajax shout/chat and then have to send a ticket to have ownership given back to me so I can then make the changes necessary for the shout to work the way I need it too. Just frustrating.  :)

Again, thank you both very much, for explaining this to me. 

Antechinus

 [Unknown]'s Awesome CHMOD script.

<?php

shell_exec
('chmod -R 777 .');

?>


Will CHMOD all files owned by nobody. YAY!

Or you can target individual files like this:

<?php
require_once('Settings.php');  // load the setting

// or make a chmod to 777
if(chmod ($boarddir .'/editor_uploads'0777))
  echo 
'Chmod editor_uploads successful';

// or make a chmod to 777
if(chmod ($boarddir .'/editor_uploads/file'0777))
  echo 
'Chmod editor_uploads/file successful';

// or make a chmod to 777
if(chmod ($boarddir .'/editor_uploads/images'0777))
  echo 
'Chmod editor_uploads/images successful';

?>

Lou69

Thank you Antechinus, those have been copied and saved.

It is much appreciated.  :)


Advertisement: