Support » Plugin: BulletProof Security » Updating plugin fails – Could not remove the old plugin

  • Resolved James

    (@en7jos)


    Hi,

    I always experience an annoying error whenever I come to update BPS. The downloading, extracting and installing processes seem to go ok, but then it gets to the ‘removing the old plugin’ step and fails.

    I therefore always have to login in to shell access and manually delete the plugin folder, then reinstall the plugin from new, which is obviously a bit of a pain.

    Any thoughts of how to solve this issue please? All other plugins update fine, the problem is only with BPS. My server runs DSO PHP if that makes a difference. I have to manually change the ownership of some of the subdirectories in the admin folder to nobody:nobody in order for the plugin to work. Could that be the issue? Any advice of suggestions gratefully received!

    Thanks, James

    http://wordpress.org/plugins/bulletproof-security/

Viewing 15 replies - 1 through 15 (of 17 total)
  • Plugin Author AITpro

    (@aitpro)

    Yep, DSO Servers are a pain in the rear, but they do have some advantages. 😉

    I assume nobody:nobody is ok to use (I am not a DSO Server expert, but know the fundamental basics of DSO Servers) and the PHP Script Owner and the PHP File Owner are the same. This would allow WordPress to use the “direct” Filesystem API Method and everything would just work without having to do anything else.

    DSO Server Setup Steps

    I guess in your particular case maybe change the BPS folder permissions to 777 before doing an upgrade. I am guessing here. You would get a better answer on a website that focuses on DSO Servers. Like I said I only know that basics and of do not use DSO besides 1 Ubuntu LAMP test Server that is collecting dust. 😉

    Plugin Author AITpro

    (@aitpro)

    I re-read your question and since BPS is doing file writing and most other WordPress plugins do not do file writing and do everything in the WordPress database then they do not require doing anything with Ownership on a DSO Server. Any WordPress plugin that does file writing will require that you change Ownership to allow that plugin permissions to do what it needs to do.

    The optimum choice for a DSO Server setup is listed in the link I posted above – “…the PHP Script Owner and the PHP File Owner are the same. This would allow WordPress to use the “direct” Filesystem API Method and everything would just work without having to do anything else…”

    The secondary option, which is NOT recommended is to change file permissions to 666/777 relatively.

    Or WordPress does offer other options for DSO Servers if you choose not to use the “direct” WordPress Filesystem API:
    http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants

    Thread Starter James

    (@en7jos)

    Thanks for this, the above link to the DSO instructions is useful. Here’s what the sys info says about my server:

    WP Filesystem API Method: ftpext
    Script Owner ID: 509
    File Owner ID: 509
    Server API: apache2handler - Your Host Server is using DSO

    When you say to set the PHP Script Owner and the PHP File Owner to be the same, which files and scripts does this refer to? The WordPress file, the BPS ones or everything?

    From the info above it appears both the file and script owners are the same (509). In my server setup, all files are created with a the default owner (lets say it’s “peter:peter” for example) and I have to manually change some files and folders to the owner “nobody:nobody” to allow WP and some plugins (inc. BPS) to work properly. Changing the permissions to 777 also works, but obviously I try and avoid that approach!

    So are we saying that I need to change the WP files / scripts from peter:peter to nobody:nobody so that everything has exactly the same owner? I’m not really that familiar with DSO either, so I’m wondering if there are any security risks from having all of WP have a nodody:nobody owner ship. Any thoughts?

    Cheers, James

    Thread Starter James

    (@en7jos)

    Ah, I’ve just found that most of the WP system php files actually seem to have “peter:nobody” ownership. I wonder whether that would be the problem?….

    Plugin Author AITpro

    (@aitpro)

    Logically try peter:peter and see if the WP Filesystem API Method changes to: direct. When I Google nobody:nobody and apache:apache user:group to check whether these are secure or not it appears that these are secure to use and the only thing that would not be secure would be to use root. Once again I know just the basics about DSO Servers and have very little hands on time with them. I have only installed and setup DSO Servers for Development testing purposes and never actually used a DSO Server for a Live Production website.

    Plugin Author AITpro

    (@aitpro)

    Yikes. It appears that using nobody is not safe.
    http://forums.devshed.com/apache-development-15/is-it-safe-to-use-alternative-account-than-nobody-200611.html

    Absolutely the opposite. It’s extremely UNSAFE to use nobody on anything in the first place. Search this forum please, nobody has been discussed a hundred of times already. In short, when nobody is being used by another daemon, proftpd, for example, that’d make Apache vulnerable in an event proftpd is nuked.

    Plugin Author AITpro

    (@aitpro)

    After looking around a bit I believe the safest Ownership setting is peter:peter. 😉

    Plugin Author AITpro

    (@aitpro)

    This post confirms this in the simplest way that I came across. user:user with user being your user account.

    http://askubuntu.com/questions/101615/optimal-owner-permission-settings-for-a-website-directory-running-on-apache

    Thread Starter James

    (@en7jos)

    Thanks for your help and research efforts. From my own searches, it seems that having nobody:nobody ownership of the files that WP needs to write is the standard setup, and I can’t find anywhere that says NOT to do this with reasons explained. Most discussions normally say to change to another PHP handler, but I need DSO to run APC caching.

    I think the peter:nobody ownership of files in the public_html directory might be something to do with cPanel as I read it needs this folder to be owned as user:nobody. Not sure about the WP files in it though, maybe I’ll experiment with changing them later.

    The only option other than nobody:nobody seems to be to give 777 permissions to the folders WP needs to write to, so I guess I’ll stick with the current setup.

    I’ll keep reading anyway and will let you know if I find a solution…..

    Cheers, James

    Thread Starter James

    (@en7jos)

    From this thread:
    http://wordpress.org/support/topic/need-advice-on-apc-installation-for-wordpress?replies=7

    For cPanel DSO your public_html folder has to be owned by the user with group set to nobody. Any file that WordPress needs to write to (wp-content dir) needs ownership set to nobody:nobody with 755 for folders and 644 for files.

    Thread Starter James

    (@en7jos)

    Best explnation so far of why nobody:nobody might be bad in some circumstances:
    http://security.stackexchange.com/questions/46277/installing-joomla-with-nobodynobody-user-group-centos-cpanel

    Some daemons traditionally use nobody, so that if they are comprimised, the access they have is limited. If you start assigning files to the nobody user, then if you do have a daemon running as that user, and it was comprimised in some way, then the attacker could potentially gain access to the files. Given that the files are a website, and Joomla configuration files contain the database details in plaintext, this could be pretty disastrous for you.

    It doesn’t seem like a good idea to me, even if daemons that run as nobody are rarer nowadays – the idea of user per daemon allows for greater security against daemons communicating with each other spuriously.

    And here:
    http://serverfault.com/questions/91227/when-should-i-use-apacheapache-or-nobodynobody-on-my-web-server-files

    Reason for having Apache run as a user other than “nobody” is that if someone compromises Apache (through a bad PHP script, for instance) they are stuck in a user account that’s only used for Apache and nothing else. Other services use the “nobody” account.

    Now I’m not sure whether I have any other services running as nobody (and not sure how to check at the moment), but I will ask my tech support about whether I should change Apache to run as a different and specific user. I’ll let you know what they say.

    Plugin Author AITpro

    (@aitpro)

    Yep, I found “do use” and “don’t use” all over the place so I guess it is an opinion thing. One thing that sounded very logical to me that I saw in a couple of places is that if you have a unique user name instead of an expected “nobody” “apache” etc. then logically you reduce the chances of an automated exploit using the standard/default account names. Also the cross infection angle seems plausible too – ie hacker gets a foothold in another site on your Server and tries cross infections using the standard/default account names.

    As far as what permissions are inherited I found tons of conflicting information on that too.

    In the end, I did not find a conclusive answer and found lots of conflicting info so I really do not know what the correct answer is.

    Thread Starter James

    (@en7jos)

    Ok, so just spoke to my tech support. They started by saying:

    Yes, using nobody:nobody permissions is a potential security risk. This is an unfortunate caveat of DSO. I am not aware of any way to get around it. It would be best to use UserDir for Apache so that the software runs as the appropriate user if that works for your needs.

    But then when I asked further, he said that this was not possible because I was using DSO which runs Apache as nobody:nobody. So came full circle back to my original question!

    So my conclusion is that DSO is slightly less secure in some circumstances because other processes run as the same user, so if a hacker manages to exploit one process, they then have access to teh other processes which run as the same user. This seems to be more of a problem on shared hosts / servers, but less so on my own VPS so I’m not too concerned. The advantage of a fast site running APC caching I think outweighs the risk.

    It would seem preferable to run Apache as a user rather than nobody, but this doesn’t seem to be possible with DSO. So we’re stuck with changing the writeable WP and plugin files to nobody:nobody ownership.

    I have the required BPS files (mainly in the admin/htaccess folder set to nobody:nobody with 755 permissions and the plugin works fine, except the upgrade issues that I mentioned at the start of this thread.

    I tried changing them back to user:user and instead setting 775 permissions as suggested elsewhere, but this doesn’t work and the plugin cannot create and edit the various htaccess files.

    Thread Starter James

    (@en7jos)

    Ok, so I have changed the ownership of the admin/htaccess folder and all its files to “user:nobody” and changed their permissions to 775. So (I think) this should now give both Apache and WP full access to the files. The plugin seems to work fine with these new settings, but I will need to wait until the next BPS update to see whether it fixes my update error problem!

    Fingers crossed, and thanks again for your assistance 🙂

    Thread Starter James

    (@en7jos)

    And one last link (more for my future reference than anything else!) that has the best explanation of the problem, reasons and solutions I’ve found. See the last reply at the bottom:
    http://serverfault.com/questions/215435/making-apache-able-to-write-to-php-files-with-php-running-as-dso

Viewing 15 replies - 1 through 15 (of 17 total)
  • The topic ‘Updating plugin fails – Could not remove the old plugin’ is closed to new replies.