On Feb 7, 2012, at 9:30 PM, Daniel Staal wrote: > --As of February 7, 2012 5:59:27 PM -0500, mikel king is alleged to have said: > >> >> On Feb 7, 2012, at 5:15 PM, David Brodbeck wrote: >> >>> On Mon, Feb 6, 2012 at 9:37 AM, dick <d...@nagual.nl> wrote: >>>> I'm a bit confused. I always believed FreeBSD is a very safe system. >>>> That may be true for the core files, but what about ports. >>>> >>>> On the net I read _never_ to let the webserver be the owner of its >>>> files and yet, ports like Drupal or WordPress make the files rwx for >>>> the owner (www) as well as the group (www). How does this fit into >>>> fbsd's safety policy? >>> >>> Content management systems are a bit of a sticky wicket for security. >>> >>> The reason for not allowing the web server user to own files is so >>> that someone who hacks a web app can't modify the site contents. But >>> the whole reason for running a CMS system is to allow modifying the >>> site contents via a web app. >>> >>> One compromise, used by TWiki and some other systems, is to make the >>> content writable by web processes but the actual code read-only. >>> That's more secure but it requires a lot of manual intervention for >>> updates and configuration changes. You *can* run WordPress this way, >>> and it will be more secure, but you'll lose the automated update >>> functionality as well as most of the web GUI configuration capability. >>> Not necessarily a problem if you have good command line fu, but it >>> can get tedious. >> >> Sounds like a good area for a maintenance tool script. Run the script >> prior to updates/config changes to temporarily open the permissions. >> After the update has been completed rerun the script to re-secure the >> permissions. Probably included a little db back in the preparation. >> >> Thoughts? > > --As for the rest, it is mine. > > So, who's running the script? If it's running from the web, you haven't > actually increased your security. And if it's running from the command line, > you haven't typically saved yourself much work. (Changing the permissions > for the folders needed for an update would typically be a one-liner, and > updating manually isn't going to be much longer; a well-designed CMS can let > you do that with a single untar command.) Of course, you could put it in > cron someplace...
CLI only. Absolutely no way I'd allow something like that to have web access. One click web crap seems nice but let's face it's not secure. One liners are nice too, but not so much fun for repeat business. I know everyone seems to be in love with one liners but my preference is the long term maintainability of a well documented script. A well written script that backs up your db, and updates the system then ensuring that the correct permissions are set as you dictate seems to be smart. But that's just the way I'd attack it. Unfortunately, WP isn't exactly a well designed CMS form the untaring standpoint. > > Of course a better solution would be to have some sort of back-end process > that the web frontend talks to, but that's a whole new layer of complexity. > (And may or may not increase security, depending on how well it's written.) > Some CMS's basically do this: They'll store all the actual pages in a > database (typically MySQL), and would only need write permissions if they are > supposed to be able to update themselves. > > Balance the security, the ease of setup, the resource load, and the ease of > adminning. Sometimes the latter are worth the loss of some of the former, if > it's done well. You can always jail the webserver as well. > Jailing is a good thought. > User's choice at that point. ;) > > Daniel T. Staal > > --------------------------------------------------------------- > This email copyright the author. Unless otherwise noted, you > are expressly allowed to retransmit, quote, or otherwise use > the contents for non-commercial purposes. This copyright will > expire 5 years after the author's death, or in 30 years, > whichever is longer, unless such a period is in excess of > local copyright law. > --------------------------------------------------------------- > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
