{"id":8800,"date":"2014-11-11T15:44:34","date_gmt":"2014-11-11T15:44:34","guid":{"rendered":"https:\/\/wp.okra.host\/article\/enabling-write-access\/"},"modified":"2021-03-07T14:51:58","modified_gmt":"2021-03-07T13:51:58","slug":"enabling-write-access","status":"publish","type":"ht_kb","link":"https:\/\/kb.okra.host\/de\/article\/enabling-write-access\/","title":{"rendered":"Freigabe des Schreibzugriffs"},"content":{"rendered":"

Overview<\/h2>\n

The web server operates in a dual-user mode for enhanced security. In order for a web application to\u00a0access your filesystem, specific permissions must be granted.<\/p>\n

Solution<\/h2>\n

Change permissions<\/a> on necessary files to 717 or 777<\/a>. For WordPress, wp-content\/uploads\/<\/code> and wp-content\/themes\/<\/code>\u00a0 should be changed recursively to allow media uploads and theme editing in-browser. If plugin editing is desired, change permissions recursively on\u00a0wp-content\/plugins<\/code> as well.<\/p>\n

The same process may be done for any other plugins or themes than require write-access to any\u00a0folder not covered above.<\/p>\n

\n

Important:<\/strong><\/span> traditionally, PHP and site files operated under one user, for two major reasons: accountability<\/em> and ease-of-use<\/em>. Accountability in that service providers providing unlimited resources can better target accounts that are unsuitable for a truly “unlimited” hosting plan (ie. consuming too many cpu resources). Running all WordPress applications under the same user allows administrators to flag abusive accounts that might lie above a bell curve<\/a>. Second, it’s easy to update files when all files accessed by the web server are owned by the same user. Permissions are not an issue<\/a>. Just let the user update WordPress from WordPress’ dashboard and done.<\/p>\n

But there’s a huge problem running under one user!<\/em> Any request on the domain, whether legitimate or forged,\u00a0can be leveraged by an attacker. Because, the HTTP request assumes the same ownership as you, any PHP exploit[1<\/a>][2<\/a>][3<\/a>][4<\/a>][5<\/a>] can be first leveraged to gain access,\u00a0then bootloaders<\/em> (simple\u00a0file managers) can be injected\u00a0into any PHP script allowing an attacker to upload malicious scripts elsewhere so long as he knows the special key.\u00a0Exploits do happen. Update\u00a0regularly!<\/strong><\/em><\/span><\/p>\n

By running as a separate user, the window of\u00a0opportunity to exploit is limited. Only files that you explicitly authorize write access<\/em> can be modified by a PHP application. If a hacker can’t modify the file, then the hacker can’t inject a bootloader or other malicious code. Only let the web server write to locations that are necessary for operation. Setting permissions to 717 on only those directories\/files that are updated regularly by a PHP application\u00a0is a great solution<\/a> to reduce your surface exposure. But, don’t set these permissions on all files or your account is just as insecure as running under\u00a0one\u00a0user.<\/p>\n<\/blockquote>\n

See Also<\/h2>\n