View Issue Details

IDProjectCategoryView StatusLast Update
0000751LDMudRuntimepublic2021-04-17 00:12
Reporter_xtian_ Assigned To 
Status closedResolutionwon't fix 
Summary0000751: using command() inside the command giver does not execute static functions in other objects
DescriptionI'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:

void init()

static int test() // not callable in per command()
  return 1;

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.
TagsNo tags attached.
External Data (URL)



2010-07-22 04:40

manager   ~0001892

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.


2010-07-22 04:56

reporter   ~0001893

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.


2010-07-22 05:09

administrator   ~0001894

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.


2010-11-18 13:36

administrator   ~0001918

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().


2011-02-24 01:12

reporter   ~0002030

+1 to keep it like it is.


2021-04-17 00:12

manager   ~0002616

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.

Issue History

Date Modified Username Field Change
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