On 8/15/2011 3:06 AM, Chris Warburton wrote:
On Friday 12 August 2011 21:23:23 BGB wrote:
newer Linux distros also seem to do similar to Windows, by default
running everything under a default user account, but requiring
authorization to elevate the rights of applications (to root), although
albeit with considerably more retyping of passwords...
Just thought I'd point out that, although Linux and Windows both seem to
prompt the user in the same way, there's a distinction in *why* the user is
prompted. With Windows the prompt is "Do you really want to do this?", with
Linux the prompt is "Prove that you are userX" (with sudo at least; some
distros still prefer su, in which case it's "Prove that you are root").
yep.
Also, from working on Web sites with a lot of user generated content, I
thought I'd point out that the permission-checking approach of BGB ends up
full of guards: either "if (has_permission(...))", and an equal number of
"else" blocks to recover in case of failure; or "throw
PermissionDeniedException(...)" and an equivalent number of "catch" blocks (or
a smaller number of catches *if* the cleanup is straightforward, but this
smells of GOTO).
I added it in right at the VM level, so most of the checks are in
strategic locations:
when accessing an object;
when applying a function object;
...
so, no real need to place permission checks all over the place.
it actually operates underneath the language, so no real need for
explicit access checks in the language.
while I was at it, I noticed/fixed a few issues relating to
class/instance objects and delegation, and added support for the new
idea of "get*" and "set*" properties.
they differ from normal properties in that they also accept the variable
name, so:
function get*(name) { ... }
function set*(name, value) { ... }
also, properties are now handled before delegating, which although
potentially not as good for performance, does have the advantage that
that things will be handled in the "correct" order (naive but slightly
faster would be to handle them when unwinding, essentially calling any
property methods in reverse order).
also had an idea for:
function call*(name, args) { ... }
but, looking over the object system code, it seems I already have a
method named "doesNotUnderstand" which does this.
checking the code (extrapolating signature):
function doesNotUnderstand(name, ...) { ... }
I could either do nothing, or a lazy option would be to make "call*" a
shorthand for "doesNotUnderstand", or adding the "doesNotUnderstand"
special method to the language spec.
Either way, there's a lot of code paths to worry about, and rolling back in
the case of failure. Worlds would be useful here (except for I/O) and the "if
(has_permission(...))" pattern could be represented by the Maybe monad (where
"foo(Nothing) = Nothing") .
it is not such an issue, as the way it is implemented doesn't really
give a crap about code paths.
technically, the VM generally just behaves as if the operation failed
with an "accessDenied" status-code (vs a "noSlot" or "noMethod" status).
the logic is actually not all that much different than from an unknown
variable/method access (actually, most of the logic is shared in-common
between these cases).
there was, after all, already logic in place for dealing with the case
when a given object does not contain a given field or method (usually
handled by delegating when-possible, or giving up with an error status).
potentially later, the VM will throw an exception in the failure +
status-code case, but for now it doesn't really bother (work is still
needed here).
The object capability model wouldn't require as many checks, as the calls are
always made, even if they're to dummy objects. This is similar to the Maybe
monad in that "foo(Nothing) = Nothing" and "dummy.foo() {return}".
possibly, but one would have to write the code into the HLL, rather than
building it into the VM.
so, I guess a tradeoff:
object-capability is better built into the HLL code, but would be more
of a pain to address at the VM/interpreter level;
permissions checking is easier to handle at the VM/interpreter level,
but could turn into an ugly mess at the HLL level.
much like threading:
threading makes far more sense in the VM, especially when it sees the
code mostly in terms of a CPS (Continuation Passing Style) like form;
trying to implement threading within the HLL would similarly turn into a
very nasty mess (watch as I try to build a multi-threaded program by
using lots of call/cc...).
so, things may have different cost/benefit tradeoffs depending on the
level in which they are implemented.
in a sense, security is sort of like the memory-access protection
features in x86.
granted, my whole point was about adding security at the VM level to
help protect against malevolent code, and not within the HLL code itself.
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
