0000751: using command() inside the command giver does not execute static functions in other objects - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000751	LDMud	Runtime	public	2010-07-12 07:03	2021-04-16 22:12

Reporter	_xtian_	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	won't fix

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 command("test"); // ... in the room for example: void init() { add_action("test","test"); } static int test() // not callable in per command() { printf("TEST!\n"); 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.
Tags	No tags attached.

External Data (URL)

Gnomi 2010-07-22 02: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.

_xtian_ 2010-07-22 02: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.

zesstra 2010-07-22 03: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.

zesstra 2010-11-18 12: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().

Coogan 2011-02-24 00:12 reporter ~0002030	+1 to keep it like it is.

Gnomi 2021-04-16 22: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.

Date Modified	Username	Field	Change
2010-07-12 07:03	_xtian_	New Issue
2010-07-22 02:40	Gnomi	Note Added: 0001892
2010-07-22 02:56	_xtian_	Note Added: 0001893
2010-07-22 03:09	zesstra	Note Added: 0001894
2010-11-18 12:36	zesstra	Note Added: 0001918
2010-11-18 12:36	zesstra	Status	new => feedback
2011-02-24 00:12	Coogan	Note Added: 0002030
2021-04-16 22:12	Gnomi	Status	feedback => closed
2021-04-16 22:12	Gnomi	Resolution	open => won't fix
2021-04-16 22:12	Gnomi	Note Added: 0002616