Title: dimlite's Replies | WordPress.org

---

# dimlite

  [  ](https://wordpress.org/support/users/dimlite/)

 *   [Profile](https://wordpress.org/support/users/dimlite/)
 *   [Topics Started](https://wordpress.org/support/users/dimlite/topics/)
 *   [Replies Created](https://wordpress.org/support/users/dimlite/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/dimlite/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/dimlite/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/dimlite/engagements/)
 *   [Favorites](https://wordpress.org/support/users/dimlite/favorites/)

 Search replies:

## Forum Replies Created

Viewing 1 replies (of 1 total)

 *   Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
   
   In reply to: [Automatic Update – Host Pair.com](https://wordpress.org/support/topic/automatic-update-host-paircom/)
 *  [dimlite](https://wordpress.org/support/users/dimlite/)
 * (@dimlite)
 * [14 years, 4 months ago](https://wordpress.org/support/topic/automatic-update-host-paircom/#post-2529792)
 * If you use your account to host multiple properties, you need to think twice 
   about this. Having your WordPress site running under your own account name means
   that any vulnerability in WordPress gives the attacker fairly significant abilities
   to modify a lot of other stuff within your public_html tree.
 * I think this is the reason Pair defaults to running most web scripts under user
   nobody. I personally don’t trust the underlying security in WordPress anywhere
   near as much as I do something like Wikipedia, where anything short of bulletproof
   is a complete show stopper. A few years back, WordPress had a reputation as a
   trivial hack. I don’t know the score more recently.
 * The contacting Pair thing has to do with directories owned by user “nobody”. 
   Ordinarily (from the command line) one would use sudo/su to chown these, but 
   Pair is more locked down. On Pair “nobody” is the user that Apache runs under,
   so any directory created by PHP scripts running under Apache will have ownership“
   nobody”.
 * I did a very quick test along these lines:
 * cd ~/public_html/mydomain
    cp -rp myblog myblog2 mv myblog myblog1 mv myblog2
   myblog
 * # lots of testing !!!!
 * rm -rf myblog1
 * In the copy, there were no “nobody”s so I think it works as advertised. WARNING:
   I didn’t actually try to run the copy as this excerpt suggests.
 * There’s more discussion of the nobody issue here:
 * [How to delete “nobody” files from a directory I own in FreeBSD?](http://www.mattcutts.com/blog/how-to-delete-files-from-a-directory-i-own-in-freebsd/)
 * I might just decide to bite the bullet and run a full site backup / site reinstallation
   cycle to achieve the upgrade under the existing security model. It’s never a 
   bad thing to dogfood your recovery plan. I had good backups for a MediaWiki site,
   but I didn’t know that an upgrade to MySQL had changed the character encoding
   for some table columns to UTF8. When my site finally did melt down, my primary
   backups were all in the wrong encoding. The secondary XML backups were OK, but
   that’s not a complete restore. Among other things, I lost all the media upload
   metadata.
 * Moral: even if you test your backup/restore on day one, it can break underneath
   you due to ongoing system upgrades in other places.
 * Rolling upgrades are great when it’s easy to jump ship. For my Linux desktop,
   I could install any other Linux distro and move on. For my web properties, that’s
   not so attractive.

Viewing 1 replies (of 1 total)