Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Feb 2012 21:54:00 -0500
From:      mikel king <>
To:        FreeBSD Questions <>
Subject:   Re: fbsd safety of the ports
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

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 <> wrote:
>>>> I'm a bit confused. I always believed FreeBSD is a very safe =
>>>> 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 =
>>>> 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 =
>>> 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.  =
>>> 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 =
>>> and it will be more secure, but you'll lose the automated update
>>> functionality as well as most of the web GUI configuration =
>>> 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.=20

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 =

> 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 =

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.
> ---------------------------------------------------------------
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to =

Want to link to this message? Use this URL: <>