"Administer Front Page" permission and PHP scripting permission.

that's a good idea DawnLight. The module is due an update soon...I'll add that new feature in when I'm updating it.

Do you need it urgently?

Dub

Have you thought through the security implications of adding the new permission 'administer front page'?
Why is this perm needed?
I am afraid that this is a very high perm to give to a user, and a user with such a perm could as well have full administrative perms throughout the web site.

The person who can administer front page could:
1) change the whole welcome page to the site, for registered users and anonymous users.
2) Add PHP code to the front page itself, i.e. use this code to give himself more rights.

I think it would be misleading to the module users to provide this feature: it might give them a false sense of security. I don't see a user being given the right to administer front page, but not having full admin rights over the whole site.

So:
1) I don't see the point of this feature.
2) At best, it just gives a misleading sense of security to webmasters who would trust someone enough to modify the content of the front page, but not enough to have access to other administrative areas (including the ability to create php code).

I vote for won't fix, unless I someone can show me I am mistaken in my analysis.

Ok, I received an email from Dub, and apparently he really wants this feature :)

I replied thus:

Giving them the 'administer front page'
permission is exactly the same as giving them full admin status. If
they don't have full admin status, but 'administer front page' they
can insert some php code in the page and this way they can update the
database and give themselves full admin status.

So this security feature is no security after all. It is only a
smokescreen that will lull web site owners into a false sense of
security.

By not adding this perm, we make it clear that front page must only be
administered by people we trust 100%, to the point of giving them php
scripting abilities!!

However, looking more closely at the code, I notice that the current perm for administering Front Page is administer menu.
'access arguments' => array('administer menu'));

Why 'administer menu'? I guess because nobody thought about anything better. And it is at least as misleading as the feature proposed above.
Thus, I reclassify this as a bug.

We can introduce a perm 'administer front page', but the implementation must be complete. I.e. proper care should be taken to handle the permission (or lack thereof) to include php code.
Drupal 5 has the perm "use PHP for block visibility". I'm not set up to run D6 on this machine, so I cannot check right now, but php filter is in another module, I believe. Do we have an undeclared dependency here?

Just to clear up any confusion. I didn't say I wanted the feature, beginner. It was requested by other users and after giving it some consideration, I judged it to be a very valid feature request and much wiser than the security risks of granting editors full admin access or as it is now, ADMINISTER MENU (???!!!!) permissions just to edit the front page.

At the moment I think the Administer Menu option is the opposite of intuitive, it's not covered in the readme.txt and is ultimately confusing.

It's far better to have a unique permission setting called ADMINISTER FRONT PAGE.

It's very common now to have multiple (trusted) editors of a site and the security risks of granting full admin access (or as it is now administer menu access) just to edit the front page is far greater than just granting ADMINISTER FRONT PAGE permission.

Yes.
"administer menu" is the wrong permission. This is a bug, as I said.

The point you keep missing, is that anyone who has access to the front page setting, can include any PHP code. This has to be solved in the patch.
Maybe we should have two permissions: "administer front page" and "use PHP code in front page".

This is an important bug, both security and useability-wise. We cannot just commit any patch or only a stop-gap. We have to do it right this time.

I really can use a 'promote to front page' permission.

So that people can post news and events and so forth to their own groups, but only certain people can post to the front page of the site and the main event calendar, without having to give them full 'administer nodes' permission.
Right now I'm probably going to hack the og module to use a different permission than 'administer nodes' when you have the 'audience required' set to true.

Maybe we should have two permissions: "administer front page" and "use PHP code in front page".

This is definitely the way to go. The "administer menu" permission doesn't make any sense and access to PHP code should ALWAYS be an explicit permission. This is bad enough it may need to go through the security team when you make the next release.

I'm also interested - due to my current requirements I'm having to remove this module.

But I have a different angle.

I completely agree about being careful RE giving PHP snippet permission etc.

Currently I have a role called editor - and I set them up with a nice theme and a simple menu which gives them direct links to nodes/blocks which need editing. I want to allow them to edit the front page - but I don't want to make them an admin user as their admin area would be too complicated.

Maybe there could be an option on the front page module to allow nodes to be used for content rather than the edit boxes. That way - I could allow the editor role to edit those pages - and as admin I could set which pages are used for the various front pages.

So, we can then allow roles to update front pages without giving them any permissions to admin front page.

@bailey: The 7.x-2.x branch has this feature built in now. The php eval is removed in favour of format filters and there is a front page permission now. In this version there is also path aliasing which I believe is what you are looking for. This allows you to select another path as the front page and it shows as if it was the home page. I am planning to port this to d6 in the next week or so. I'll let you know when it's ready.

Thanks,
Tim

Hi guys, I've now finished 6.x-2.x branch which is now available for download as dev version. If some of you could try it out and report back we can get it released quicker.

Thanks,
Tim

Unassigning.