View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000178LDMud 3.5Compilation, Installationpublic2004-11-26 21:192018-01-30 03:59
ReporterlarsAssigned Tozesstra  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000178: Make garbage_collection() and shutdown() privileged.
DescriptionShort: shutdown()/ garbage_collection() priviledged
From: Matthew Julius <julius.2@wright.edu>
Date: Fri, 08 Jan 1999 16:29:08 -0500
Type: Feature
State: Unclassified

Make shutdown() and garbage_collection() call master::privilege_violation().

Note: Most muds solve that with nomask simul-efuns.
TagsNo tags attached.

Activities

zesstra

2009-09-27 16:41

administrator   ~0001320

I am in favor of this, it is much more consistent.

fufu

2009-10-01 12:41

manager   ~0001393

I would rather move in the opposite direction and not call privilege_violation for any efuns at all, leaving just two causes: "limited" and "nomask simul_efun". But perhaps that's just me.

What about set_environment?

zesstra

2009-10-04 09:56

administrator   ~0001447

Mhmm, ok, I prefer to have the checks for privileges in one spot, no matter which they are. I see one big advantage in privilege_violation in the master: The checks can be implemented by
switch(fun) {
  default: return -1;
  ...
}
This causes access to forgotten or new efuns to be denied. With the sefun approach you should better not forget an efun - especially a nuisance for new ones.
Furthermore, I see one a difference between that approach: if you just restrict things by "nomask simul_efun" and sefuns, then privileged objects use efun::fun() and that is a compile-time decision for a given program. (And that program you have to safe-guard accordingly.) In privilege_violation the check is usually based on the object currently executing the program, which is IMHO in most cases what you want.
I am more comfortable by the central place of privilege checks in privilege_violation. It seems more robust to me.

set_environment() should IMHO also cause a privilege_violation, as well as set_this_player(). But these two efuns are a bit more difficult, because they are usually bound to the moved object, which are usually not privileged.

zesstra

2009-10-07 07:09

administrator   ~0001513

Setting to feedback for further discussion before I make any changes. ;-)

Sorcerer

2009-10-08 05:31

updater   ~0001515

I agree with Zesstra with respect to having all privilege checks in one place. The main reason being the argument given above concerning privileged objects and/or new efuns.

zesstra

2010-11-16 18:10

administrator   ~0001912

Ok, as far as I see there are two (three, counting the reporter) in favor, one against and a lot of indifferent people. So I will continue.

zesstra

2010-11-17 23:19

administrator   ~0001917

Fix committed in revision e73d914a767c759afccd677b9d4857b22b8bfc81 to master branch (see changeset 724 for details). Thank you for reporting!

zesstra

2018-01-29 18:59

administrator   ~0002337

Fix committed in revision e73d914a767c759afccd677b9d4857b22b8bfc81 to master branch (see changeset 1617 for details). Thank you for reporting!

zesstra

2018-01-29 21:57

administrator   ~0002388

Fix committed in revision e73d914a767c759afccd677b9d4857b22b8bfc81 to master branch (see changeset 2949 for details). Thank you for reporting!

zesstra

2018-01-30 03:59

administrator   ~0002439

Fix committed in revision e73d914a767c759afccd677b9d4857b22b8bfc81 to master branch (see changeset 4030 for details). Thank you for reporting!

Issue History

Date Modified Username Field Change
2004-11-26 21:19 lars New Issue
2009-09-27 16:41 zesstra Note Added: 0001320
2009-09-30 14:44 zesstra Status new => assigned
2009-09-30 14:44 zesstra Assigned To => zesstra
2009-10-01 12:41 fufu Note Added: 0001393
2009-10-04 09:56 zesstra Note Added: 0001447
2009-10-07 07:09 zesstra Note Added: 0001513
2009-10-07 07:09 zesstra Status assigned => feedback
2009-10-08 05:31 Sorcerer Note Added: 0001515
2010-11-16 18:08 zesstra Status feedback => assigned
2010-11-16 18:10 zesstra Note Added: 0001912
2010-11-17 23:01 zesstra Project LDMud => LDMud 3.5
2010-11-17 23:02 zesstra Category Efuns => Compilation, Installation
2010-11-17 23:02 zesstra Product Version 3.2.8 and before =>
2010-11-17 23:02 zesstra Target Version => 3.5.0
2010-11-17 23:19 zesstra Source_changeset_attached => ldmud.git master e73d914a
2010-11-17 23:19 zesstra Source_changeset_attached => ldmud.git master 447fa283
2010-11-17 23:19 zesstra Source_changeset_attached => ldmud.git master 37edd43b
2010-11-17 23:19 zesstra Note Added: 0001917
2010-11-17 23:19 zesstra Status assigned => resolved
2010-11-17 23:19 zesstra Resolution open => fixed
2017-10-04 18:56 zesstra Fixed in Version => 3.5.0
2018-01-29 18:59 zesstra Source_changeset_attached => ldmud.git master e73d914a
2018-01-29 18:59 zesstra Source_changeset_attached => ldmud.git master 447fa283
2018-01-29 18:59 zesstra Source_changeset_attached => ldmud.git master 37edd43b
2018-01-29 18:59 zesstra Note Added: 0002337
2018-01-29 21:57 zesstra Source_changeset_attached => ldmud.git master e73d914a
2018-01-29 21:57 zesstra Source_changeset_attached => ldmud.git master 447fa283
2018-01-29 21:57 zesstra Source_changeset_attached => ldmud.git master 37edd43b
2018-01-29 21:57 zesstra Note Added: 0002388
2018-01-30 03:59 zesstra Source_changeset_attached => ldmud.git master e73d914a
2018-01-30 03:59 zesstra Source_changeset_attached => ldmud.git master 447fa283
2018-01-30 03:59 zesstra Source_changeset_attached => ldmud.git master 37edd43b
2018-01-30 03:59 zesstra Note Added: 0002439