[drupal-devel] [feature] Do not install a PHP code format by default

Wed Jul 27 09:55:31 UTC 2005

Issue status update for 
http://drupal.org/node/27330
Post a follow up: 
http://drupal.org/project/comments/add/27330

 Project:      Drupal
 Version:      cvs
 Component:    database system
 Category:     feature requests
 Priority:     normal
 Assigned to:  chx
 Reported by:  chx
 Updated by:   kbahey
 Status:       patch

That was not what I meant.

What I meant was to prevent the PHP filter programmatically from being
exposed where it should not (e.g. nodes, comments), while allowing it
where it should (e.g. blocks).

The problem so far is that it is exposed in places (or for users) where
it should not be. 

Exploits are caused by bugs that humans do while they program. That is
a fact of life, and will not change as long as humans write code. 

Whatever these bugs are caused by Drupal (not PHP), is within our
control, and we should fix them. 

I realize this will not work in all cases, but in most, that should
work.

Clearer now?

kbahey

Previous comments:
------------------------------------------------------------------------

Sat, 23 Jul 2005 18:03:58 +0000 : chx

Attachment: http://drupal.org/files/issues/dbinit.patch (2.04 KB)

Those users that are advanced enough that they need PHP pages, will be
able to create a custom input format.

------------------------------------------------------------------------

Sat, 23 Jul 2005 18:08:42 +0000 : Bèr Kessels

+1 for the idea. Untested, though.
Chx, do yuo not need to default the node-settings?

------------------------------------------------------------------------

Sat, 23 Jul 2005 18:19:31 +0000 : TDobes

This is one of Drupal's best features.  Why should we hide it and/or
make things more difficult for so-called "advanced users?"  I feel that
the ability to create PHP pages and PHP blocks should be part of the
out-of-box experience. (available without any "extra steps" on a fresh
install)  A first-time user looking for this ability might get
discouraged and give up before finding the "input formats" screen and
realizing that they must create a new item.

Also, this might be a problem resulting in support requests if people
get confused and combine other filters with the PHP parser filter.

------------------------------------------------------------------------

Sat, 23 Jul 2005 18:45:41 +0000 : nevets

Interesting, I thought it was general disabled by default (but
installed).  I think it should be part of the default install because
it very useful in creating custom blocks and nodes.

------------------------------------------------------------------------

Sat, 23 Jul 2005 18:53:02 +0000 : adrian

I'm going to +1 this. 

php input format is deadly.

------------------------------------------------------------------------

Sat, 23 Jul 2005 19:25:40 +0000 : Junyor

Just because something is powerful, doesn't mean it should be hidden
away.  How can you make custom PHP blocks without this input format?

------------------------------------------------------------------------

Sat, 23 Jul 2005 19:57:27 +0000 : TDobes

Junyor:  No you can't.  Which is why I'm -1'ing this.

I think the opposing argument is that people who really need to make
custom PHP blocks and/or nodes could create the input format
themselves.  However, I think this is an insult to the intelligence of
someone who knows PHP well but may not necessarily be familiar with
Drupal (yet).

------------------------------------------------------------------------

Sat, 23 Jul 2005 19:58:47 +0000 : Junyor

As I figured.  -1.

------------------------------------------------------------------------

Sat, 23 Jul 2005 20:05:25 +0000 : Gerhard Killesreiter

I'd prefer the filter to be defined but disabled.

------------------------------------------------------------------------

Sat, 23 Jul 2005 20:21:44 +0000 : kbahey

-1 from me. 

PHP input is needed in many blocks and pages I use, for example adsense
module.

There has to be a better way of handling the security side effects of
PHP input, for example, making sure that it really is restricted for
anon users and access control really works the way it should.

------------------------------------------------------------------------

Sat, 23 Jul 2005 21:03:34 +0000 : Steven

-1: I imagine this will lead to improper set ups, where people place the
filter in the HTML format instead of creating a new format with the
filter in it. When told they need to enable PHP support on their site,
people will look for a checkbox that says "PHP Filter" and check it.
And it will not cause any visible problems, because PHP only kicks in
between <?php ?> tags.

------------------------------------------------------------------------

Sun, 24 Jul 2005 08:39:15 +0000 : Bèr Kessels

Steven, you are right. As are the others that say 'it is too hard to
turn it on'. But as Steven also said " the filter admin is pretty bad,
but the problem is that it is quite complicated;.. none of the mockups
made before had all the necessary functionality in them"
I agree with this. Steven is right when he points out the filter UI is
bad. I would like to go as far to say it is horrible. But I too have no
clue as how to fix it. So this is not a rant on that UI; Just to point
out that the part that is broken is the UI.

Thus, I think we should keep security tight and switch off PHP. And
then, as next step, fix he system and UI. Let s not leave security
"holes" open, because we cannot get our interfaces right.

------------------------------------------------------------------------

Sun, 24 Jul 2005 09:45:34 +0000 : Bèr Kessels

Allright. Talk is silver, code is gold, and mockups ar egold-withsilver
:) Please comment on http://drupal.org/node/27364

------------------------------------------------------------------------

Tue, 26 Jul 2005 10:09:50 +0000 : Dries

+1 (I suggested to disable the php code format)  Better safe than sorry,
whether you like it or not.  Many sites got hacked because we messed up.
 We can't allow that to happen again.  Security is more important than
ease of use.  Given the PHP code filter is for power users only, we'll
be good.

------------------------------------------------------------------------

Wed, 27 Jul 2005 09:17:44 +0000 : kbahey

The issue is not the presence of PHP as a valid input format. 

The issue is that this is exposed in situations that it should not be
exposed, or to users who 

It is not ease of use, but features. Many features will be broken by
the lack of this filter. Examples are Google Adsense, Banner module,
all the PHP code snippets, ...etc.

If this is temporary, while we secure it, I have no problem with it.

a better approach is to include the filter by default, but not make it
enabled by default. In this case, the site admin makes a concious
decision to enable it.

In all cases, can we document why we did this, and how to enable it (at
one's own risk), so we do not get swamped with support requests with
4.7?

------------------------------------------------------------------------

Wed, 27 Jul 2005 09:29:39 +0000 : Goba

Kbahey, I don't know what you mean by "until we secure it". PHP has no
security model, if you allow people to run arbitrary PHP code typed in
by themselfs, they can do anything unsecure. Nothing will prevent them
from this. Creating another layer of security (ie. inventing another
scripting language on top of PHP) might help, but I doubt anyone is
going to do it.