Menu
▾
▴
#2 Linklocking
Linklocking -- basically, if a linklock is set on an
object, then only things that pass the lock will be
allowed to set a link to that object.
[Should it be environmental, or default to checking the
owner's linklock if it's not set on the object?]
Areas to code for:
@link
prog_can_link_to() (p_db.c)
prim_setlink()
prim_setlinks_array()
Should there also be a readlinklock?
Logged In: YES
user_id=175712
If administrators expect this to apply everywhere, they may
be disappointed. Some programs that create links but run at
a higher permission level than the user do not call the
built-in link permissions (because there is no way to call
them), but rather are forced to emulate them; when the
built-in permissions change, the programs' emulations of
them do not change. I see this as a stumbling block to
implementing alternate access control schemes.
Logged In: YES
user_id=7718
actually, there is a way to call them: prim_link calls
can_link_to(). There's no reason an additional primitive
(CANLINK) couldn't be added, or add something like canlink,
canchown, canforce, cancreate, candig, etc... the same way
the in-server ignore stuff works, to check against the
various locks.
I'm all about exposing the in-server functionality to the
users, when it makes sense to do so. (You don't want to
return the actual boolexps to the program, but you do want
to be able to check against them.)
Logged In: YES
user_id=7718
hmm... but upon rereading your comment, you're right.
However, it /is/ possible to check uid and "me" match and
see if they're listed in the allow list. (This would allow
setuid programs to work in the case where the coder wants to
allow access to link, but only through his code... or
harduid, if the trigger needs to check for validity before
allowing it to occur.)
Check my suggestions for force<m4, and think if those
concepts could be extended to this type of locking?
Logged In: YES
user_id=175712
Yes; my point is that there isn't a way, not that there
couldn't be. It would be nice if there were; at the moment,
lib-prem contains crude emulations of
can-link?
player-can-read?
player-can-write?
muf-can-read?
muf-can-write?
because there are many instances where a library is M3 or M4
and needs to check to see whether its caller or current user
can access something. (Crude emulations mostly because for
a library there is _no way_ to obtain the current UID
reliably, AFAICT.)
At present there are, I suspect (I'm too lazy to actually
try to enumerate them at the moment), many programs which
run with relative privilege and just do something like
player @ obj @ controls obj @ "L" flag? or if
( Okay to link. )
whatever @ obj @ setlink
then
because there isn't any other good WTDI, and as soon as
there's _one_ of these as a global command or linkable
program, it breaks the entire idea of switching the access
control mechanism around.
Defaulting to checking the owner's linklock if there isn't
one on the object seems bizarre, since linking to the owner
is an unrelated action; checking up the environment isn't
much better, so I'd just default to the setting of the L
flag if there isn't a _/lklk property (or whatever it would be).
Your suggestions for non-superuser force seem reasonable,
and they could be applied here as well, but there is also
the question of who should be permitted to even _determine_
whether such-and-such user could link to whatever. Perhaps
check the call chain for this? Then there's that M2 and
above can always just read the property anyway, unless it's
placed in @/ rather than _/, but then suddenly programs that
want to make objects semi-linkable as the current user have
to be superuser.
Logged In: YES
user_id=175712
(Clarification: "relative privilege" = "relatively high
privilege" in paragraph 4 of previous comment.)
@linklock implemented in fb7a.