map settings are always run with access level Owner
Bug #307753 reported by
Yann Kaiser
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Armagetron Advanced |
Fix Released
|
Critical
|
Manuel Moos | ||
Bug Description
To reproduce:
1/ Write a map that has <setting name="USER_LEVEL" value="someguy@ 0"
2/ Set yourself as Administrator(1) on a server.
3/ Enter the game and use in-game admin to select your map
4/ /listadmins and see someguy@ is now Owner
Related branches
Revision history for this message
| Yann Kaiser (epsy) wrote | #1 |
| Changed in armagetronad: | |
| importance: | Undecided → Critical |
| milestone: | none → 0.2.8.3 |
| status: | New → Confirmed |
Revision history for this message
| Manuel Moos (z-man) wrote | #2 |
| Changed in armagetronad: | |
| assignee: | nobody → z-man |
| status: | Confirmed → Fix Committed |
| Changed in armagetronad: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Well spotted. Settings in map files are now executed with the access level of the one setting MAP_FILE. Error messages triggered are only reported on the server's stdout and I have no ambition to get them to the remote admin, too.
I've also made it a requirement to have a tCurrentAccessLevel object in every scope where settings are executed to prevent stuff like that from creeping up in other places. I adapted all the places I could find; but there may still be some assertion failures in tCurrentAccessL