View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000751||LDMud||Runtime||public||2010-07-12 09:03||2021-04-17 00:12|
|Summary||0000751: using command() inside the command giver does not execute static functions in other objects|
|Description||I'm not sure if this is a bug or not, the manpage is not clear in that regard.|
The situation is as follows:
The player-object uses a efun::command("xxx"); to execute an action (like in the unitopia style mud client emulation).
static functions are not callable this way!
Trivial code example:
// ... in the player
// ... in the room for example:
static int test() // not callable in per command()
As the command() executes inside the command-giver itself this case does not seem to pose a security risk in my opinion.
If the command( . , ob) Syntax were used or the command() were executed from another object than the command giver (like a shadow?) it would be a security risk.
|Tags||No tags attached.|
|External Data (URL)|
It might break security in current mudlibs. In some mudlibs the player object offers lfuns to call command() (because calling it on other objects was not available until a while ago), which are not specially guarded (except when called on wizards). I have seen such an lfun in Morgengrauen and UNItopia, so I suspect there are many more mudlibs with such lfuns out there.
And a few years ago the method of choice to protect important actions against calls by somebody other than the current player was to make that action static. Allowing command(str) (called by the lfun, which was called by someone else) to call static actions would break that.
To reinstate that security a mudlib might call command() via a proxy object, but that might break other security devices (in UNItopia we have as an alternative to static actions an inherit that checks the caller_stack()). So I'd rather not implement this suggestion, because I see no easy way for a mudlib to adapt its security checks to it.
I understand. I guess we will have to move to caller-stack() based security, too.
Although not fixing this really makes "static" functions conceptually broken (or at least their last unique use), in my opinion.
In new code in MG static is considered deprecated (although old wizards are still getting used to that...).
One remaining use may be using call_other on this_object() if you don't know if then function exists. Some people prefer to use call_out("fun",...) instead of call_out(#'fun,...), but I don't see that as compelling reason of static in favor of protected.
I would also prefer to keep it like it is, because we have a ton of commands which might be affected.
But we should add a note about this to the manpage of command().
||+1 to keep it like it is.|
||As mentioned in the notes due to the security implications we don't want to change the current behavior regarding static functions. Therefore closing the ticket.|
|2010-07-12 09:03||_xtian_||New Issue|
|2010-07-22 04:40||Gnomi||Note Added: 0001892|
|2010-07-22 04:56||_xtian_||Note Added: 0001893|
|2010-07-22 05:09||zesstra||Note Added: 0001894|
|2010-11-18 13:36||zesstra||Note Added: 0001918|
|2010-11-18 13:36||zesstra||Status||new => feedback|
|2011-02-24 01:12||Coogan||Note Added: 0002030|
|2021-04-17 00:12||Gnomi||Status||feedback => closed|
|2021-04-17 00:12||Gnomi||Resolution||open => won't fix|
|2021-04-17 00:12||Gnomi||Note Added: 0002616|