Spinning off a ticket from #1505270: Paranoia Roadmap for Stable D7 Release (see #6).
A role with the "Administer users" permission cannot edit uid 1's passwords or email, but they CAN edit their username. This doesn't pose a security risk per se, but it can block them from logging in as normal, which could set off a false positive that the account was compromised.
Therefore, I would recommend either 1) removing the form's username field for uid 1's edit page OR 2) change it to a markup field that simply displays the username as normal text.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1549542-uid1-name-5.patch | 802 bytes | greggles |
| #1 | 1549542-uid1-name-1.patch | 636 bytes | rickmanelius |
Comments
Comment #1
rickmanelius commentedI decided to go the easy route and simply remove the username field completely. I was planning on setting the #disabled attribute so as to still show it, but I read in the Pro Drupal Development book (edition 3) that this doesn't necessarily prevent submitting a value by DOM manipulation. So to be truly safe, I just dropped it.
Here's the patch. It's a simple 1 line addition.
Comment #2
rickmanelius commentedForgot to set the status...
Comment #3
gregglesSeems reasonable to me. Anyone else have an opinion?
Comment #4
rickmanelius commentedI think everyone else is too scared to answer
(insert more 'paranoia' puns)
:)
Comment #5
gregglesThere's also a warning message that needs additional text now.
Comment #6
rickmanelius commentedI can set to RBTC (reviewing patch #5) as it's a trivial edit on #1 which you already RBTC for my initial patch.
If that's kosher, we're all set... and no one has chimed in for 2 months, so it doesn't seem like anyone else has any strong opinion (and that can be a new ticket).
Comment #7
gregglesThat's what I was hoping you'd do :)
So, great, committed - http://drupalcode.org/project/paranoia.git/commit/45cea70
Thanks, rick!