[lkml]   [1998]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2.1.97] more capabilities support

    >With pure capabilities on the other hand, time and storage required to
    >perform a check is always constant: 0 (zero), because the check is done
    >implicitly at the object border, so the object does not have to waste
    >any resources to perform it explicitly.

    Ah, now I see where the confusion is coming from. Andrej, you are using
    "pure capability" in a way that's very different from most of the
    published literature. You're assuming an object-oriented design, and
    the Unix/POSIX interface is manifestly *not* object-oriented.
    Furthermore, if you look at the literature, the capabilities predate
    object oriented designs by a very long time.

    Your idea of checking at the object border might work fine if you have
    objects, and if the objects are properly designed ahead of time with
    security properities in mind. For example, let's take it out of the
    kernel application domain, and talk about a purchasing system, since
    it's easier for most people to understand.

    Suppose the interface involved is "purchase an item". If that is the
    interface, than a check at the "object border" can only be, "allow the
    user to purchase an item". However, this is not useful; we may want to
    express the authorization "allow the user to purchase items under
    $5,000". Or perhaps the authorization rule is "allow the Ted to
    purchase normal items under $5,000 but not radioactive chemicals
    (because he hasn't taken the radiation safety course yet)."

    In your model, a "pure capability system" that only checks items at the
    border can only do the first check --- "purchase an item". It's
    possible you could change the interface to allow checks to only happen
    at the object border, but I question whether it really can be done. In
    any real system, the application usualy has to get involved in
    authorization decisions, because such decisions tend to involve
    application-specific decisions. In the kernel, for example, it's not
    enough to block out all socket calls. You might want to block out the
    ability to bind to ports below 1024.

    One could imagine a totally different kernel API which was completely
    and totally incompatible with POSIX, where you might be able to make all
    interface checks "at the object boundary". However, for the reasons
    stated above ---- I doubt you could make it work even then.

    Given that we want to be POSIX compatible, the POSIX capabilities really
    are the best way to go. If you want to play with a totally
    object-oriented kernel interface ---- go try to find a research OS
    that's playing games in that area.

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.022 / U:2.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site