undeletableusers und superadministrators können im modcp gesperrt werden

[dhr]

Hallo zusammen!

Dieses Verhalten ist IMCO ein böser Bug. Die "undeletables" würde ich mir noch eingehen lassen, da von der Programmier-Logik her die "superadmins" darüber liegen. Letztere sollten aber keinesfalls geändert werden dürfen - schon gar nicht durch Mods mit weniger Berechtigungen.

MfG

Daniel Reichelt
ITaM-Services

[Pathor]

Ich kann meinen Co. Superadmin nicht sperren (Angegebener Benutzer ungültig).

Hast du den Admin und die unlöschbaren Benutzer in der includes/config.php eingetragen?

// ****** UNLOESCHBARE / UNVERAENDERBARE BENUTZER ******
// Alle hier angegebenen Benutzer koennen im Administrator-Kontrollzentrum
// von anderen Benutzern nicht geloescht oder bearbeitet werden.
// Trennen Sie mehrere User-IDs mit einem Komma voneinander (s.o.).
$config['SpecialUsers']['undeletableusers'] = '3,4';

// ****** SUPER-ADMINISTRATOREN ******
// Alle hier angegebenen Benutzer koennen im Administrator-Kontrollzentrum die
// Seite fuer die Administrator-Berechtigungen aufrufen und damit die Rechte
// anderer Administratoren bearbeiten.
// Trennen Sie mehrere User-IDs mit einem Komma voneinander (s.o.).
$config['SpecialUsers']['superadministrators'] = '1,2';
Hast du da vielleicht die Benutzernamen eingegeben und nicht die User-IDs?

[Gandalf2003]

hab auch gerade mal den test gemacht, und ich kanns auch nicht!

[dhr]

Hi!

Die entspr. Einträge habe ich sicherlich in Form von User-IDs gemacht.

Hab mich auch falsch ausgedrückt. Der Mod der Sperren kann, ist nicht Mod sondern in einer Gruppe Supermods ("Nur-Mods" können undeletables und superadmins nicht sperren, das ist richtig).

Hier ein SQL-Dump der Gruppen-Berechtigungen meiner Gruppe "SuperMods":

INSERT INTO `usergroup`
(`usergroupid`,
`title`,
`usertitle`,
`canmodifyprofile`,
`pmsendmax`,
`maxforwardpm`,
`genericoptions`,
`ispublicgroup`,
`canoverride`,
`description`,
`opentag`,
`closetag`,
`forumpermissions`,
`pmpermissions`,
`calendarpermissions`,
`wolpermissions`,
`adminpermissions`,
`genericpermissions`,
`passwordexpires`,
`passwordhistory`,
`pmquota`,
`attachlimit`,
`avatarmaxwidth`,
`avatarmaxheight`,
`avatarmaxsize`,
`profilepicmaxwidth`,
`profilepicmaxheight`,
`profilepicmaxsize`)
VALUES
(10,
'SuperMod',
'Moderator',
1,
0,
0,
22,
0,
0,
'',
'',
'',
983039,
3,
63,
31,
1,
36183791,
0,
0,
200,
0,
128,
128,
20000,
100,
100,
100000);


Noch ein Indiz für einen Design-Fehler: Im Admincenter können keine Admins - nicht einmal S-Admins - das Profil eines anderen S-Admins ändern.

Werde mich mal durchwühlen, wo in den modcenter-Scripts diese Berechtigungen abgefragt werden.

MfG

[Pathor]

Die entspr. Einträge habe ich sicherlich in Form von User-IDs gemacht.

Dann hast du auch sicherlich in der ./includes/config.php nachgeschaut. ;)
Poste doch mal das, was ich auch schon gepostet habe.
http://www.vbulletin-germany.com/forum/showpost.php?p=145115&postcount=2

("Nur-Mods" können undeletables und superadmins nicht sperren, das ist richtig)

Noch nicht einmal ein S-Admin kann einen undeletable User bearbeiten (auch selbst kann man sich nicht im AdminCP bearbeiten).

[dhr]

Hab den Fehler gefunden:

in der modcp/banning.php zeilen 249-252

if (!$user OR $user['userid'] == $vbulletin->userinfo['userid'] OR $user['usergroupid'] == 6)
{
print_stop_message('invalid_user_specified');
}

wird nur auf usergroupid==6 (admins) geprüft und ggf. das Skript mit einem Fehler abgebrochen. Allerdings wird NICHT geprüft, ob die userid in undeletables oder s-admins in der config.php drinsteht. ich werd das mal als bug-report verfassen....

cu & thx

PS: Link zum Bugreport
http://www.vbulletin.com/forum/bugs35.php?do=view&bugid=2492