I'm a bit baffled here. But it might just be my lack of experience.
I have setup PHP DSO (mod_php) and my server runs smoothly and stable. The issue is, though, that in order to run php with includes and everything, I had to set all user account files (/home/*/public_html/*) owner to nobody:nobody.
This introduces two questions for me:
- Is this really necessary? I'd rather have them user:user
- What about FTP? If I upload files using FTP, they're owned by user:user so they can't be included in another php file (throws errors). Files that are owned by nobody:nobody can't be modified through ftp..
FYI: I also have SuEXEC enabled. Should I disable this?
FYI2: I know I could set all permissions to 777, but that's just wrong.
Thanks a lot!
Ordinary "nobody" should only read executing files, and write/own only files that can be changed by php. Most files owner should be your ftp user.
Bad practice to keep php rights to change executable files.
Also if "nobody" has rights to run as root it provides php (and therefore users) all his rights.
Related
I'm currently working to make a WordPress plugin of mine compatible with nginx. This plugin requires access to a .conf file in the wp-content/uploads directory, so that it can add in the required rules. Currently, it updates an .htaccess file in the same directory, and the changes take effect immediately without intervention. Because nginx requires service nginx reload to allow configuration changes to take effect, I am looking for a way to do that in my script. I'm not sure that even exec() would work for this, as service nginx reload is required to be run as root or using sudo. I've searched far and wide on StackExchange, Google, and everywhere else that I know of, and I can't even find a starting place.
Security wise, it would be a VERY bad thing to give the user that runs the web server sudo/root access. Rather, you could use a semaphore file and have a cron job run by root that runs every 5 minutes (or higher frequency if required) that looks for the presence of this file. If present, it issues the service nginx reload command and deletes the file.
My Suggestion
Overall I think the best solution would be to have your plugin create specific instructions for the user to edit any Nginx config manually and then reload Nginx themselves.
I believe this because giving PHP the ability to run a command that usually requires sudo requires opening up a large security hole.
On top of that, the methods that a user would have to do in order to allow PHP to run the service nginx reload command is not something you can accomplish in PHP alone, and may be equally, if not more, complex than having them update Nginx config and reloading themselves. The user needs to do extra work regardless!
If you really want to do this:
If you still choose to go down this course of action, I suggest having users of the plugin edit the server's /etc/sudoers file, which can allow user www-data (or any other user) to run that one specific command using sudo without requiring a password. This also means that the user (perhaps www-data) would NOT have permission to run any other command, which is at least a bit more secure.
Use the sudo visudo command to edit the /etc/sudoers file. Don't edit it directly.
Here's the line to add to that file for user www-data:
www-data ALL=(ALL:ALL) NOPASSWD:/usr/sbin/service nginx reload
Here's an example of allowing a user (group) to run similar commands, with some more explanation. Here's more on Sudoers and how /etc/sudoers works.
Lastly, note that user www-data is specific to installing Nginx on Debian/Ubuntu Linux distributions. Other very common distributions (centos, redhat, fedora, arch, etc etc etc) may not be running Nginx/PHP-FPM as user www-data unless the sysadmin creates those users manually.
Short answer: Bad idea. Don't do it.
Long answer: What you try do to cannot be compared with editing a .htaccess file simply because it does not work the same way. .htaccess files are made to be edited and reloaded on the fly and can be created and accessed almost in every directory inside your public directory.
That is not the case for Nginx configurations. Configuration files are made to be loaded when Nginx starts or manually when needed. Their location is related to the configuration defined by the administrator.
Even if you knew where the file was, it could be impossible for you to update it or write in that specific directory.
More than that, you'll have to figure out what user can write and read where the configuration files are located.
In the end, there are so many thing that can go wrong. In my humble opinion, the idea is really bad.
What most plugins do is display the Nginx configuration that should be included so the website administrator can copy and paste it. Or, they create a .conf file that the website administrator must copy somewhere before restarting Nginx.
What you try to achieve is doable. It can be coded. Don't get me wrong. BUT your plugin will become about handling every specificty of every Nginx configuration there is out there. You really don't want that.
As you don't know every configuration (and honestly, you don't want to know), I'd suggest you focus on developing a great plugin and offering the right Nginx configuration via the plugin. The last part (where the website administrator copies it to the right location and reloads the configuration) is his job.
The other answers I read in that question suggest ways of "trying" to achieve what you are asking. I think they will create more problems than they'll help. By changing permissions and running crons, it may work. But you'll also open the door to security vulnerabilities as your www-data user or website user owner will now be considered as root and could run things that should not be run. I would not advise you to do that.
You must add correct permissions to account www-data which is used to execute commands on Linux webservers. You see which account is executing script with PHP by using <?php echo exec("whoami"); ?>
I am trying to install Joomla 3.2 using the host provided by my university. So, I have available one mysql database with the username and pass and the ftp username and pass to transfer data, only. That is, no Cpanel installed or ssh available.
If I extract the file Joomla_3.2.0-Stable-Full_Package.zip and ftp the contents on the website, the owner of these files/folders is user "ftp_username". I can continue to install Joomla only if I set-up the ftp layer.
This works, except I get from time to time messages like --> JFTP: :rename: Bad response Rename failed More specifically I get this message when using kunena.
Moreover, I read online that the FTP layer shouldn't be used normally. Also, the tmp/cache/logs create permission problems.
If I remove the ftp layer (by editing the configuration.php) then I cannot modify anything since Joomla cannot modify the files (owned by ftp_username). Of course, I could change all permissions to 777, but that would be suicide...
I found a post explaining a bit the situation I'm here! Especially the advice on using "chmod 4770" is feasible but I don't know about how secure it is (haven't tried it).
Anyone has an idea how I can make this work?
cross-posted here
Thanks in advance
I found a way to bypass this problem. Not worth it if you have an alternative provider!
I installed joomla with ftp layer
I installed Extplorer plugin
Used plugin to upload Joomla_3.2.0-Stable-Full_Package.zip on the server. Now the file is owned by the apache user.
Deleted all the (joomla installation) files on the server except the zip file
Uploaded a php script to unzip the file using php (http://php.net/manual/en/ziparchive.open.php). The installation folders/files are now owned by apache user
Reinstall Joomla without the ftp layer.
I guess I could have used some php uploader script instead of steps 1-4, but I already had Joomla installed with the ftp layer.
That's it. Up and working. If you have an alternative provider, don't bother.
It seems to me that the hosting option provided by the university may be too restrictive to work for pretty much any CMS. You need to be able to chmod and potentially chown all your files in bulk so as to avoid insanity.
There may be an FTP program out there that will chmod your files as you are uploading them. If your group is www-data or whatever group apache needs, then you can 775 your folders and 664 your files; you should be good to go.
I have a CMS which i made with PHP and i want to add some self updating features to it.
A self updating system can be a complex and tedious thing, i know that, but that's a whole different story. The bottom line is is that i end up creating new PHP files, editting existing ones with new code and probably deleting some PHP files when an update happends.
I know how to read, write and delete files in PHP, but this almost always gives me problems on a Linux server when i don't chmod the folder with an FTP client first to 0777.
I also know PHP has chmod and chown functions. But most of the times these functions don't work for me either. Mainly because all the PHP files are uploaded through FTP which gives the rights to write to files and folders to the FTP group (or something like that).
I also have a Wordpress blog installed on a Linux server, but for some reason this Wordpress site has no trouble updating itself. I assume it does the same things i said; create, update and delete certain files. But none of the Wordpress sites i ever worked with complained that it couldn't update itself because of the folder/file permissions.
So i'm guessing Wordpress uses a smart way to change folder permissions when needed. I just couldn't figure out how.
So basically my question is, what is the best way to give PHP permissions to chmod files and folders on a Linux system? How does a system like Wordpress handle this?
You can set the folder to 0777 which would give PHP the capability to create files inside of it. You can also chown the folder to www-data or whatever your copy of PHP runs as...
I am not much of a web developer, so apologies in advance for this dumb question.
I have a test server (Centos 6.3) with LAMP set up for me to play around. From what I understand, the server executes whatever is in /var/www/html directory. How do you edit source files in that directory ? Do you do a sudo vim "foo.php" each time you want to fix something (or add something ) ? I'd imagine that would be a pain when you are building a complex application with many files and directories .
This is what worked for me. For the record this is a Centos 6.3 server running LAMP (On Rackspace).
First, I found out that apache runs as user "apache" and group "apache" on centos systems. In other distros, I believe it runs as "www-data" in group "www-data". You can verify this by looking at /etc/httpd/conf/httpd.conf. We need to change ownership of /var/www to this user. Replace "apache" below with "www-data" if that is the case for you.
chown -hR apache:apache /var/www
Now lets make it writable by the group:
chmod -R g+rw /var/www
Add yourself to the apache group:
usermod -aG apache yourusername
Replace apache with www-data in the above if thats the case for you.
Now log out and log in - you can now edit the files, ftp them to this directory or do whatrever you want to do.
Comments welcome. TNX!
There are many approaches to modifying and deploying websites/web apps.
CentOS 6 is, by default, accessible with SSH2 on port 22. If you are on Windows you can use a combination of PuTTY and WinSCP (to manage your server, and its files, respectively). If you're on Linux or Mac OS X, SSH is already built into your system and can be accessed with Terminal. I find that using SSH is favourable over other methods because of how widely supported, secure and lightweight it is.
You'll also need a decent text editor or IDE to edit the files if you want proper syntax detection. There's tons of choices, my favourites are Notepad++ and Sublime Text 2. Not to say that I haven't edited my PHP files from time to time using the nano text editor package directly in PuTTY (yum install nano).
If you're using a edit-save-upload approach, just remember to back up your files regularly, you will find out the hard way if you fail to do so. Also, never use root unless you need to. Creating a user solely to modify your websites is good practice (adduser <username>, and give that user write access to /var/www/html).
To answer your second question:
Once you get into heavier web development you will probably want to use something like Git. Deploying with git is beyond the scope of this question so I won't get into that. In brief, you can set it up so your development environment sits locally and you can use a combination of git commit and git push to deploy.
I use a FTP client (FileZilla) to download files, edit them and then re-upload them. If you're a one (wo)man show, and on a test setup and just playing around to learn, this is probably sufficient. With more than 1 person, or going to a (test and) production setup, you should look at some more control with svn like #Markus mentioned in another answer.
You should change the permissions of that directory (with chmod) so you have write permissions, and can then read and write to that directory. Then, you don't need sudo.
dude. read up on version control and source code control systems like subversion and git. the idea is to develop on your machine, revision control the result, then deploy a known working version on the production server.
After years of using chmod 777 to solve PHP write permission woes, I want to know the proper way of solving the problem.
I have a website on my server owned by user1 in group user1. There is a folder in this website called uploads.
Normally to get writing with PHP to work, I have to chmod this folder to 777. But I obviously recognise this is dangerous and incorrect, and I want to setup the permissions properly to minimise risk.
From my limited knowledge, I see two options,
I chown the uploads folder so that it's owned by apache. This way, I can just use the default permissions and apache can happily write to the folder.
I add a second group to apache of user1. I then give write permission to the owner and group on uploads, which should allow apache to write to uploads?
My question is, what is the best approach? Is it one of the above or something completely different?
If the best solution is #1, how can user1 also write to uploads over SFTP as that solution will not let them?
In my current company, we set the apache group to the group that owns the folder, so you just need to do chmod 770 on the folder to give permissions to that particular group to do funny stuff on that folder.
However you still to remember to protect your application from malicious user, as the PHP script being run, if sufficiently insecure, can still do damage to the folder.
If it's your own server, the best way is to set the folder to the group apache uses, e.g. with chgrp www-data on debian (might be different on other systems). You usually have to do this as root or at least as a user who has access to his own and www-data group. If your user has access to www-data group, this might be a cool feature for you since its easy then to read and maybe write/move the files.
In this case, use 770 as the file permission and ensure that files created by php get this permission (either explicitly after creating with chmod or with umask before creation. See php manual for both.)
If you are working on a shared hosting environment, the only clean solution I know is mod_suexec, but I don't know many hosters that enable it. If this is not available I know only the way you do know, working with 777. Often, your home directory in shared environments have a longer random string in the path name so that others should not find your directory and therefore can't access your files. But this is not real security.. ;-)
Good luck
Michel