Mudlib security with nomask/inherits()?

[fleacircus]

I've been having fun tinkering with a nearly from-scratch MudOS mudlib, but now I've reached the point where I need to consider mudlib security before I go any further.  (I should note I'm really only concerned about file security, and not interested in the driver-provided uid and privs stuff. And shadows are disabled.)

So I have a basic question about the thing I'm basing my security on.

Objects that want file access must inherit "/secure/access", which defines a function nomask int query_access_level().

Given that, is the master's valid_write/read() function safe to do something like this:

Code: [Select]

int valid_write(string file, object caller, string func)
{
    int access_level;
    if(!inherits("secure/access", caller)) return 0;
    access_level = caller->query_access_level();
    ...thinking that the query_access_level() defined in /secure/access.c must be called?

Some testing has me a little bit worried; inheriting "u/blackhat/bogus_access" (which defines query_access_level()) before inherit "secure/access" only results in a compiler warning. obj->query_access_level() still hits the right place, but this seems like a bug to me.

[chaos]

Since the nomask query_access_level() seems to be overriding properly, you may be safe doing that, but honestly it isn't an approach I'd take in general.  I would always prefer to make determinations about authorization without depending on the objects whose authorization is in question for any information other than their pathnames.  So, in a setup like yours, I might determine "access level" with a get_access_level() sefun rather than an lfun.

[Nulvect]

I'd like to point out that what chaos suggested is normally done using the driver-provided UID system. This is what NM 3 does, as well as DS at least as far as 2.8.2 (the latest version I have downloaded). You use seteuid() in your code, which calls valid_seteuid() in the master object, and THAT checks a few different configuration files to see if the object is ok to have that permission.

It works ok, and I would even recommend it for what you are trying to do, fleacircus. The only downside is having to keep a list of extra permissions for every object that might need them.

I know you said you weren't interested in the UID thing, but if you're concerned about your original approach, I see no reason to reinvent the wheel here. Since you'd be writing the implementation yourself you wouldn't need to worry about any extra baggage that may come with a lib-provided security system that uses UIDs.

[fleacircus]

Thanks for the wise advice