[Carnage]

Originally Posted by KirbyDE

Not supporting hacked boards is one thing, "intentionally" increasing the danger of security leaks is another.

As said, this is a hypothetical worst-case scenario and most likely won't ever happen.
But it is far more dangerous to use an unused bit for custom things then adding a column to a table (the upgrade script would crash with a mySQL-error if a column with this name does already exist when they try to ALTER TABLE) or introducing new variables (this can of course also cause problems, but only if Jelsoft uses the same variable name; Bitfields will be used sooner or later)

Btw: Creating such a "issuperadmin" usergroup permission IMHO would be pretty easy: In init.php check the bit, if it is set also set ismoderator and cancontrolpanel.
In can_administer() check that bit and if it is set return true, no matter what $do is.

Yes well, i'm not going to release the hack in question since i didn't write most of it in the first place... so it'll only be on the board it was written for. In the event of any upgrades, I can easilly change admin permissions if the need arises.

the superadmin user permission is slightly more difficult than that, you have to go through and find every check for the In_array($superadmins_array) thing(can't remember the exact script) and replace it with a check to that permission, however as a quick way to grant all normal permissions, yes it is quite simple.

My intention with it was to have it function in the same way we had root admins function on vb2, root admins were the ones who controlled admin permissions, they were the only ones able to grant access to the admin and root admin forums, plus they had a bunch of other useful things such as the ability to change peoples userid and to add elements to the rpg system we used. However it turned out alot more difficult than i though it would be I may have another go at doing something like this when i've got other things sorted out.