Port Paranoia to Drupal 6

So, where's your patch?

So are you offering up a different version do you just not have it in a format to submit a patch?

How different is this than what paranoia already does?

Has anyone reviewed this new code? Would be nice to have some feedback from the core team.

kranklin: would be good to have this in patch form, so that we can review the actual changes required.

At least I can provide it as a patch. It removes several features and adds others of dubious value...

certainly needs work.

I will work on this as it is needed for the drupal.org upgrade: http://groups.drupal.org/node/17294

Patch attached for Drupal 6 version.

Used some of the ideas from the previous patch but removed the additional features (these belong in separate issues from the D6 port).

Added paranoia_requirements to give site status errors if PHP block visibility permission is set for a role, or if the PHP module is somehow enabled.
Added hook_paranoia_hide which allows other modules to be removed from the module admin form.
Added an install file to disable PHP module if it is enabled.
Updated the README.

I removed the code that prevents disabling, deleting, and email/password changes of the superadmin. I felt that this code was ineffective because the admin/user/user access to disable/delete the superuser still exists. If this functionality is important we'll need to prevent it from both angles.

Thanks, I've applied this patch and created the D6--1 branch for further work.

Excellent. It worked for me too when I applied the patch. Looking forward to seeing the dev version up on Drupal.org.

Why not keep it fixed?

@Gábor - I imagine the goal was to get the snapshot release on the project page. I've done that.

For most people I know, the ability to block changes to the superadmin is the whole reason why we use this module. Otherwise, we end up getting locked out of sites we're maintaining because someone went in and changed a password. This is especially true of a multi-site set up we have where each site belongs to a different county organization within the state organization. Before we installed this, on multiple occasions we had to go into the database and manually edit the superadmin user to give us access to the site.

Without that ability, we run the risk of once again someone going in and changing the superadmin account so they can make changes they're not authorized to do. And we can't just shut down their ability to add/edit users since they need to be able to create and edit their local users of the site.

We haven't actually implemented the dev version of this code on any of our sites yet. Wanted to see that there was a bit more life in pushing this project to release a stable candidate first. However, looking at the project usage, it does seem to be getting used on live sites with D6 at the moment - http://drupal.org/project/usage/paranoia

We generally don't give most of our clients user/1 access to the site unless they are moving it to their own hosting environment. The restrictions to user/1 seemed to be a nuisance for sure (so I can sympathize with removing it), but if anyone admin access for users can modify the email address or password for the superuser then there's a lot less security.

We're mostly concerned with implementing this for multi-site instances on servers that we are managing. This code would still addresses the PHP vulnerabilities that are an issue with multi-sites.

PHP hasn't been an issue with us on the big multi-site we're running. It's just been the access to the user/1 account. When we used the D5 version of paranoia, the information on the account couldn't be edited unless you did it directly into the database (and they don't have that access).

Since they need to be able to edit their local users, I don't see any way to protect the user/1 account without this module working like it did under D5.