Don't let the all administrator accounts get blocked

It is not nice to have an option which lets admin account to be blocked by oneself, it sounds like a trivial bug for me . I have rolled a patch to fix this, please test it and let me know your suggestions. There is already an issue #46149: Prevent account cancellation for uid 1 sound like killing oneself and more relevant to this.

Thanks to Heine for giving that link.

There are use cases to block the UID = 1 account. I generally do it myself.

i go with the title of this issue, reasons

• It is not uncommon to see newbies trying out all the options in settings page.
• A good software must forgive the users mistake http://www.usabilitypost.com/2009/04/15/8-characteristics-of-successful-...
• check out there links http://drupal.org/node/46149#comment-372154 users are smart enough to delete admin account and search for a change to restore it.

Conclusion : At least the user should be warned with some message when he/she tries to block admin account :P.

#46149: Prevent account cancellation for uid 1.

If it's not a duplicate, this issue should at least take into account the heavy discussion in that thread.

Unduplicating this because the referenced issue only handled the cancelation of UID1 (as far as I can see from reading through this massive issue). http://drupal.org/node/46149#comment-1910166 brought this problem up but was ignored. Also #792784: You can block user #1, locking yourself out of the admin panel!.

Preventing the cancelation of UID1 was to prevent killing a site. Blocking UID1 can mean nearly the same ESPECIALLY for inexperienced users.

Note: http://drupal.org/project/userprotect will be available for D7 so we can handle this via contrib although my guts are telling me that this should be handled directly.

Thoughts?

I think, at the very least, it should pop up a warning, asking if we're SURE we wish to block the admin account.

I applied the patch and tested it with the bulk operations from /admin/people (as this is where I first stumbled upon this problem).

Sadly the patch in #5 didn't seem to catch here. How was it tested?

Comparing it to #46149: Prevent account cancellation for uid 1 it seems like they added a bunch of testing into their patch. Should be a very similar patch.

I do think that user/1 shouldn't be blocked, ever.

#4 above says he has use cases for disabling admin / uid 1... But never elaborated on this...

I don't see how it would make the site more secure, if someone can hack into the admin account, they could probably hack into the database and just unblock the admin account...

If there IS a use case, I think it needs a warning box to pop up (with a checkbox allowing you to make it not show anymore)... I can't think of what that use would be though..

Moving to Drupal 8.

A somewhat related issue that (depending on your point of view) might make this one obsolete is at #920250: Users should not be able to easily to block their own account (i.e., without email confirmation). Given that the user 1 account already can't be blocked via the "cancellation" process, that issue (which had an initial patch already committed) would basically mean that there's no way for user 1 to block themselves.

That would seem to meet the primary goal here, while still meeting Damien's goal in #4:

#4 above says he has use cases for disabling admin / uid 1... But never elaborated on this...

I don't see how it would make the site more secure, if someone can hack into the admin account, they could probably hack into the database and just unblock the admin account...

I think it's the same reason people turn off password logins for root on a webserver. You don't want someone to be able to brute-force attack the user 1 account with a password dictionary and totally own the site. That would happen entirely via the Drupal UI.

Of course, you should definitely have secure passwords also... but if you block the account, that's the most secure way to prevent anyone from ever logging in as user 1.

You don't want someone to be able to brute-force attack the user 1 account with a password dictionary and totally own the site. That would happen entirely via the Drupal UI.

That may be true, but how hard is it to find out a secondary account that has "administer users" or "administer permissions" and then brute force that?

If we did it, the fact that some people *want* to block this account means to me that we would need to make it overridable. This feature/protection seems to me like unnecessary code bloat that we should won't fix.

...friendly bump.

I think it's a "won't fix". I appreciate that we need to take care of new users, but I don't see this as a particulalry common/painful problem.

Agreeing with #17. Uid 1 can also be blocked in D5, 6 & 7. I think this is a feature that should be available. I think #7 makes a solid argument but the admin user should know what he's doing.

The point is to not allow the website to be completely locked to admins. Since after D7 we have the notion of an administrator role instead of a single super-admin account, I think it is best to prevent the last active admin account (could be other than uid 1) from being blocked.

... Uid 1 can also be blocked in D5, 6 & 7. I think this is a feature that should be available. ...

...unless somebody presents a valid use case where all admin accounts should be blocked, this remains a bug and not a feature. IMO it is a design flaw because it could lead to potentially undesired and non-reversible results.

Updating title based on the proposal in #19.

What you're now proposing will only work if we have an idea of the admin role (i.e. a standard install, not a minimal) or if we define some permission to be fundamental to an admin role in the case of a non-standard install (minimal install or distributions). That seems like a fair amount of code to stop someone from shooting themselves in the foot.

IMO it is a design flaw because it could lead to potentially undesired and non-reversible results.

Yes, it is probably undesired in 99.999% of the cases. But no, it's not irreversible.

One other thought: we often determine what core should do based on what contrib and install profiles do. Are there any contrib modules or distributions that fix this bug?

http://drupal.org/project/userprotect fixes it to some extent, but it does so in a very general way that doesn't directly address the current question/idea.

Came across this in #1851086: Replace admin/people with a View. A related question is whether we should allow user 1 to be blocked at all.

@xjm - that idea was discussed and discarded in #46149: Prevent account cancellation for uid 1 so I think the answer is yes, there are lots of scenarios where people want to do that. Marking this as a duplicate of that (again). Since I first mentioned it there has been some light discussion back and forth with a lot of folks saying they want to be able to block admin accounts.