[opensuse] Please help understanding use of chmod and chown to get Wordpress installed
I asked about this on a Wordpress group, but they said this is a Linux question rather than a WordPress question. That I must ask reflects only that when it comes to administering a Linux box, I am a complete novice, even though I have been programming for decades. On the following page (http://codex.wordpress.org/Updating_WordPress), I find the following: "Automatic Update "Current versions of WordPress (2.7+) feature an Automatic Update. You can launch the automatic Update by clicking the link in the new version banner (if it's there) or by going to the Tools -> Upgrade (or Update for version 3) menu. Once you are on the "Update WordPress" page, click the button "Update Automatically" to start the process off. You shouldn't need to do anything else and, once it's finished, you will be up-to-date. "For Automatic Update to work, at least two criteria must be satisfied: "(a) file ownership: all of your WordPress files must be owned by the user under which your web server executes. In other words, the owner of your WordPress files must match the user under which your web server executes. The web server user (named "apache", "web", "www", "nobody", or some such) is not necessarily the owner of your WordPress files. Typically, WordPress files are owned by the ftp user which uploaded the original files. If there is no match between the owner of your WordPress files and the user under which your web server executes, you will receive a dialog box asking for "connection information", and you will find that no matter what you enter in that dialog box, you won't be able to update automatically. "(b) file permissions: all of your WordPress files must be either owner writable by, or group writable by, the user under which your Apache server executes. "On shared hosts, WordPress files should specifically NOT be owned by the web server. If more then one user owns different files in the install (because of edits made by deleting and re-uploading of files via different accounts, for example), the file permissions need to be group writable (for example, 775 and 664 rather then the default 755 and 644). File permissions (in general) should be adjusted as appropriate for the server environment (the shared host RackSpace CloudSites for example recommends 700 and 600 for a single ftp user, or 770 and 660 for multiple ftp users). See the file permission section for more (some files and folders require stricter permissions). " However, On the following page (http://codex.wordpress.org/Hardening_WordPress), I see: "Some neat features of WordPress come from allowing various files to be writable by the web server. However, allowing write access to your files is potentially dangerous, particularly in a shared hosting environment. "It is best to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create specific folders with less restrictions for the purpose of doing things like uploading files. "Here is one possible permission scheme. "All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process. "/ The root WordPress directory: all files should be writable only by your user account, except .htaccess if you want WordPress to automatically generate rewrite rules for you. /wp-admin/ The WordPress administration area: all files should be writable only by your user account. /wp-includes/ The bulk of WordPress application logic: all files should be writable only by your user account. /wp-content/ User-supplied content: intended to be writable by your user account and the web server process. "Within /wp-content/ you will find: "/wp-content/themes/ Theme files. If you want to use the built-in theme editor, all files need to be writable by the web server process. If you do not want to use the built-in theme editor, all files can be writable only by your user account. /wp-content/plugins/ Plugin files: all files should be writable only by your user account. "Other directories that may be present with /wp-content/ should be documented by whichever plugin or theme requires them. Permissions may vary. "Changing file permissions "If you have shell access to your server, you can change file permissions recursively with the following command: "For Directories: "find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; "For Files: f"ind /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \; What I do not understand is how to reconcile the ownership and mermissions required for automated updates with what is best to make the site as hard as is practicable. Note, this is for a multidomain install, but I own the hardware, so I do not know if this counts as a shared host or not. Note, I have not yet installed Wordpress on the machine in qustion, although I have downloaded and unpacked the latest release (so I can begin editing the configuration file as I need to do). As I did so using my account, I guess that means my account is deemed by the SOS to be the owner, and I do not know if I need to change ownership of some or all of the files once I move them all to document root (as the Wordpress installation instructions tell me to do), or if I need to do something else (I do not have a budget to let me hire a system administrator to do this for me, and indeed, in a business environment, I'd be relying on the MIS to handle all of this sort of thing). Can someone explain to me how one reconciles the ownership and permissions requirements for updates with those for ensuring system security, and what series of commands I should enter to put that into effect (relating that to the documentation of chown and chmod, would help me understand the how of it, if you don't mind).? Thanks Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Ted, On 05/31/2013 10:46 PM, Ted Byers wrote:
Can someone explain to me how one reconciles the ownership and permissions requirements for updates with those for ensuring system security, and what series of commands I should enter to put that into effect (relating that to the documentation of chown and chmod, would help me understand the how of it, if you don't mind).?
first of all, I do not use WordPress on a productive system, so others may be able better to point you to some nice documentation. However, I can try to explain the principle. On your Linux server, the webserver is run by a dedicated user account. For static web pages, it is sufficient that this apache user can read the files. In such an environment, you would usually upload the files with your own user account, and set the permissions on these files so that the apache can read, but not write them. Instead of the numeric values in your examples - which you can read about e.g. with `info coreutils`, node 'Setting Permissions' - this would be "u=rw,go=r" (user can read+write, users in the same group and other users can only read it). Directories will additionally need the 'x' permission for all in order to be searchable. However, as WordPress stores data in certain places you have entered via the web interface, the apache user needs to be able to write to these files/directories. There are 2 options: either the files have the same group as the apache user and you give it 'g+w' (group writeable) permissions, or you open the permissions to every local user with 'o+w' (writeable to others). The note about installations maintained by several users targets the situation where these accounts all belong to the same group and the files are group writeable (plus writeable by others if the apache user requires it for running WP). See also: * info coreutils 'chmod invocation' * info coreutils 'chown invocation' * info coreutils 'chgrp invocation' Again, you have to consult the WP documentation to know which parts do or do not have to be writeable by the apache user. Hope this helps. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, May 31, 2013 02:46:25 PM Ted Byers wrote:
I asked about this on a Wordpress group, but they said this is a Linux question rather than a WordPress question. That I must ask reflects only that when it comes to administering a Linux box, I am a complete novice, even though I have been programming for decades. On the following page (http://codex.wordpress.org/Updating_WordPress), I find the following:
"Automatic Update
"Current versions of WordPress (2.7+) feature an Automatic Update. You can launch the automatic Update by clicking the link in the new version banner (if it's there) or by going to the Tools -> Upgrade (or Update for version 3) menu. Once you are on the "Update WordPress" page, click the button "Update Automatically" to start the process off. You shouldn't need to do anything else and, once it's finished, you will be up-to-date.
"For Automatic Update to work, at least two criteria must be satisfied:
"(a) file ownership: all of your WordPress files must be owned by the user under which your web server executes. In other words, the owner of your WordPress files must match the user under which your web server executes. The web server user (named "apache", "web", "www", "nobody", or some such) is not necessarily the owner of your WordPress files. Typically, WordPress files are owned by the ftp user which uploaded the original files. If there is no match between the owner of your WordPress files and the user under which your web server executes, you will receive a dialog box asking for "connection information", and you will find that no matter what you enter in that dialog box, you won't be able to update automatically.
"(b) file permissions: all of your WordPress files must be either owner writable by, or group writable by, the user under which your Apache server executes.
"On shared hosts, WordPress files should specifically NOT be owned by the web server. If more then one user owns different files in the install (because of edits made by deleting and re-uploading of files via different accounts, for example), the file permissions need to be group writable (for example, 775 and 664 rather then the default 755 and 644). File permissions (in general) should be adjusted as appropriate for the server environment (the shared host RackSpace CloudSites for example recommends 700 and 600 for a single ftp user, or 770 and 660 for multiple ftp users). See the file permission section for more (some files and folders require stricter permissions). "
However, On the following page (http://codex.wordpress.org/Hardening_WordPress), I see:
Can someone explain to me how one reconciles the ownership and permissions requirements for updates with those for ensuring system security, and what series of commands I should enter to put that into effect (relating that to the documentation of chown and chmod, would help me understand the how of it, if you don't mind).?
Thanks
Ted In all the years I've run Wordpress, I've never done this. Although I don't self host anymore, I find it strange that this is necessary. My install is hosted, and when a new version comes out, the dashboard lets me know about it and I do the update. It works and I keep right on running.
One thing about security though, is never use admin as the administrative user. Use something like Ted4056. Then a good password, and it will deter hackers. They go for the admin user first. Mike -- Powered by SuSE 12.3 Kernel Tumbleweed 3.9.3.10.g06ad9d8.X86_64 KDE 4.10.2 16:48pm up 7:47, 3 users, load average: 8.16, 8.27, 8.30 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 31 May 2013 16:46:25 -0400 Ted Byers wrote:
I asked about this on a Wordpress group, but they said this is a Linux question rather than a WordPress question. That I must ask reflects only that when it comes to administering a Linux box, I am a complete novice, even though I have been programming for decades. On the following page (http://codex.wordpress.org/Updating_WordPress), I find the following:
"Automatic Update
"Current versions of WordPress (2.7+) feature an Automatic Update. You can launch the automatic Update by clicking the link in the new version banner (if it's there) or by going to the Tools -> Upgrade (or Update for version 3) menu. Once you are on the "Update WordPress" page, click the button "Update Automatically" to start the process off. You shouldn't need to do anything else and, once it's finished, you will be up-to-date.
"For Automatic Update to work, at least two criteria must be satisfied:
"(a) file ownership: all of your WordPress files must be owned by the user under which your web server executes. In other words, the owner of your WordPress files must match the user under which your web server executes. The web server user (named "apache", "web", "www", "nobody", or some such) is not necessarily the owner of your WordPress files. Typically, WordPress files are owned by the ftp user which uploaded the original files. If there is no match between the owner of your WordPress files and the user under which your web server executes, you will receive a dialog box asking for "connection information", and you will find that no matter what you enter in that dialog box, you won't be able to update automatically.
"(b) file permissions: all of your WordPress files must be either owner writable by, or group writable by, the user under which your Apache server executes.
"On shared hosts, WordPress files should specifically NOT be owned by the web server. If more then one user owns different files in the install (because of edits made by deleting and re-uploading of files via different accounts, for example), the file permissions need to be group writable (for example, 775 and 664 rather then the default 755 and 644). File permissions (in general) should be adjusted as appropriate for the server environment (the shared host RackSpace CloudSites for example recommends 700 and 600 for a single ftp user, or 770 and 660 for multiple ftp users). See the file permission section for more (some files and folders require stricter permissions). "
However, On the following page (http://codex.wordpress.org/Hardening_WordPress), I see:
"Some neat features of WordPress come from allowing various files to be writable by the web server. However, allowing write access to your files is potentially dangerous, particularly in a shared hosting environment.
"It is best to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create specific folders with less restrictions for the purpose of doing things like uploading files.
"Here is one possible permission scheme.
"All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.
"/ The root WordPress directory: all files should be writable only by your user account, except .htaccess if you want WordPress to automatically generate rewrite rules for you. /wp-admin/ The WordPress administration area: all files should be writable only by your user account. /wp-includes/ The bulk of WordPress application logic: all files should be writable only by your user account. /wp-content/ User-supplied content: intended to be writable by your user account and the web server process.
"Within /wp-content/ you will find:
"/wp-content/themes/ Theme files. If you want to use the built-in theme editor, all files need to be writable by the web server process. If you do not want to use the built-in theme editor, all files can be writable only by your user account. /wp-content/plugins/ Plugin files: all files should be writable only by your user account.
"Other directories that may be present with /wp-content/ should be documented by whichever plugin or theme requires them. Permissions may vary.
"Changing file permissions
"If you have shell access to your server, you can change file permissions recursively with the following command:
"For Directories:
"find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;
"For Files:
f"ind /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;
What I do not understand is how to reconcile the ownership and mermissions required for automated updates with what is best to make the site as hard as is practicable. Note, this is for a multidomain install, but I own the hardware, so I do not know if this counts as a shared host or not.
Note, I have not yet installed Wordpress on the machine in qustion, although I have downloaded and unpacked the latest release (so I can begin editing the configuration file as I need to do). As I did so using my account, I guess that means my account is deemed by the SOS to be the owner, and I do not know if I need to change ownership of some or all of the files once I move them all to document root (as the Wordpress installation instructions tell me to do), or if I need to do something else (I do not have a budget to let me hire a system administrator to do this for me, and indeed, in a business environment, I'd be relying on the MIS to handle all of this sort of thing).
Can someone explain to me how one reconciles the ownership and permissions requirements for updates with those for ensuring system security, and what series of commands I should enter to put that into effect (relating that to the documentation of chown and chmod, would help me understand the how of it, if you don't mind).?
Thanks
Ted
Hi Ted, Two worthwhile links for your review: WordPress File Permissions http://wpmu.org/wordpress-file-permissions/ This second item is actually referenced inside the first: WP File Permissions & Size Check Plug-in http://wordpress.org/extend/plugins/wp-file-permission-check/ hth & regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Bernhard Voelker -
Carl Hartung -
mike -
Ted Byers