Make users always have a new dbref
tanabi opened this issue · 4 comments
Someone was mentioning to me today the hilarity that can happen when a MUF program uses dbrefs to track permissions, access, or whatever and then a player gets toaded and their ref gets recycled into an exit, room, or object that now shows up on the 'wizards' or 'staff' or whatever list of players.
This is, in part, "poorly" programmed MUF. Well programmed MUF would check player? before trusting a random dbref. I put poorly in quotes because this is kind of a weird edge case and I'm sure I've missed the edge case a few times in my own programs.
However, one thing that cannot be solved easily -- what if a player ref is recycled into another player? This would be unlikely on a large and busy MUCK, but on a smaller MUCK? It could potentially happen. And thus, this becomes an obscure security hole in the MUCK.
The simple solution is to make players always have a new ref (i.e. always increasing the size of the database when a player is created). I don't see a downside to this. One might argue that it could lead to a runaway increase of the database on a MUCK with open registration ... but that's already a problem because a MUCK of any size will eventually run out of 'recycled' refs to use and start to expand. And it ensures that a new player will never get the ref of an old player.
This will probably involve adding a flag to new_object(...) to indicate if it should always use a fresh DB or not, then fixing all calls of new_object (looks like 5 total calls) to make that flag false for most cases but true for player. As such, this is an excellent first issue for anyone that wants to take a stab at it.
Even without toading and recycling being involved, assuming a wizard or staff member will remain a wizard or staff member seems... ill-advised. But making security-lax MUF that little bit less insecure seems like a worthy enhancement when it'll be so simple to implement.
To make it a little more complicated, the issue title says "option". Should this be a tuneable option, a compile-time option, or non-optional?
To make it a little more complicated, the issue title says "option". Should this be a tuneable option, a compile-time option, or non-optional?
When I was first writing the issue, I thought option because I was thinking there could be a theoretical downside to new refs for players.
However, as I was thinking through it, I couldn't come up with anything. So I took the word option out, let's just make this how it works.
I actually vaguely recall reading something about reserving low ref numbers with dummy objects for later assigning to wizards. Not only does that seem superfluous in itself, but you can make the dummy objects players themselves, then just @name them instead of recycling to free the ref number before doing a @pcreate.
I've never taken charge of an issue before, but I have contributed a little. I can close my PR to let an even-newer contributor tackle it, if that's appropriate.