Took me a little while to find, but here's where it started.
Note that anyone could have found this if they bothered to take the time to search, which I did !
With links and content quoted.
http://lists.contribs.org/pipermail/devinfo/2006-December/009462.htmlOn Wed, 20 Dec 2006, Greg J. Zartman, P.E. wrote:
> I'll put together a regular install howto soon, but here's a basic one:
>
> 1. Create a new dbase for the addressbook.
>
> 2. Create an ibay called addressbook.
...
Please don't reinforce the design pattern of using ibays for web
applications. Create a small httpd.conf template fragment to enable web
access only to the files which need to be accessed via http. See webmail
as an example.
Charlie
http://lists.contribs.org/pipermail/devinfo/2006-December/009464.html> Please don't reinforce the design pattern of using ibays for web
> applications.
I prefer this method of deploying apps of this type on my setup as it
doesn't require me to hack config files, only later to forget what I
did. If I get tired of the app, I just delete the ibay and it's gone.
However, your comment begs the question of why the ibay config panel
includes this:
Execution of dynamic content (CGI, PHP, SSI)
Greg
http://lists.contribs.org/pipermail/devinfo/2006-December/009465.html> However, your comment begs the question of why the ibay config panel
> includes this:
>
> Execution of dynamic content (CGI, PHP, SSI)
Well, it *raises* the question, anyway.
I remember a great deal of discussion at Mitel about this issue. I did a
fair amount of research into secure methods of allowing non-root users
and groups to run executable content in ibays, and ultimately we decided
that there was no safe way to do so without making things dangerously
complex and raising the resource requirements beyond a level that we
were comfortable with.
Our compromise decision was to turn off the ability to run
PHP/Perl/Whatever on the webserver without the express permission from
the admin user. Hence the flag above. It's an imperfect solution.
The problem is an obvious one: Making it too easy to install a (possibly
poorly-written) CMS-du-jour can compromise the security of the entire
system. Encouraging people to install new applications (even web apps)
using a consistent and proven process encourages better - and safer -
integration.
I'm not assuming this was Charlie's rationale, but it sounds like reason
enough to me.
Dan McGarry