Homework 12 Solutions

22C:116, Spring 1997

PROBLEM 1

        The protection bits for the 9 operations given can be
    assigned as follows:

        INFO - no need for protection since it has no effect
    upon the object inquired;

        GETPARAMS, STATUS - only one bit can be used for
    protection on both these operations; they return parameters
    or status information associated with the server and are
    usually used by the system administrator;

        SETPARAMS - may need a separate bit than the above two
    since it can modify the server's parameters and this needs
    to be restricted even if reading information is permitted;

        DESTROY, AGE - the former needs protection for obvious
    reasons; a malicious user repeatedly calling AGE on an object
    might be able to force it to grow old and die!  Since the risk
    is a risk of slow and unpredictable deletion, AGE and DELETE
    can share a right.

        RESTRICT - needs no protection, since the only thing
    restrict allows is for a user to obtain a capability that
    grants less access to an object than the user originally
    had, and a verbatim copy of a capability can be made with
    no rights at all, just by copying the bit pattern.

        COPY - note that this does not copy the capability, it
    makes a new copy of an object.   As such, it may need to be
    protected.

        TOUCH - probably needs no protection, other than the
    standard server-side authentication check to see if the
    capability is indeed valid.  Most servers would probably
    touch objects when they perform any operation on them!

PROBLEM 2

        The capabilities of Amoeba correspond to the links in
    DEMOS, and the ports of Amoeba are similar to the
    message-queues of DEMOS.
        The capabilities can be passed among processes as the
    links were in DEMOS. But ports are not bonded to a
    particular process; they are arbitrarily chosen by a
    process each time it needs to receive a message.

PROBLEM 3 PART A

        A minimum of three messages must be exchanged by client
    and server, if the burden of detecting duplicates is left
    to the server side:
        - the request from the client;
        - the reply from the server;
        - the acknowledgment for the reply, from the client.
        A strategy with a fourth message can be used, making
    the server send an acknowledgment for the request, but this
    doesn't solve the problem since the acknowledgment can be
    lost. Protocols using sequence numbers for each message can
    be used.

PROBLEM 3 PART B

        Messages are not queued in Amoeba. The put-ports are
    being queued in a table by the server. When the server
    performs a get-request it checks the table for the
    indicated port, and then data is copied from sender to
    receiver.

PROBLEM 3 PART C

        The pseudo-codes for the three system calls are:

    get_request(&header, buffer, bytes) {
        if there is an unmatched get_request
            exit with error;
        else
            receive(&header, buffer, bytes); /* blocking */
            extract information about request from header;
            call RPC procedure with this information;
    }

    put_reply(&header, buffer, bytes) {
        if there is not the matching get_request
            exit with error;
        else
            pack the reply from the RPC procedure;
            send(&header, buffer, bytes); /* blocking */
    }

    trans(&header1, buffer1, bytes1, &header2, buffer2, bytes2) {
        send(&header1, buffer1, bytes1); /* send request */
        receive(&header2, buffer2, bytes2); /* wait for reply */
    }

PROBLEM 4

        The following operations can be implemented using a
    standard implementation:
        TOUCH, AGE - they simply reset or increment a counter
    representing the age or time since last use, which can be
    done in a uniform way for all the objects;
        GETPARAMS, SETPARAMS - they read or change a parameter
    block of information for the server, not for an object;
    while the format of this status block may depend on the
    server, the services for updating it need not depend on the
    server -- although a callback the server can use to add
    custom code when the parameters are changed would be useful.
        STATUS - could be implemented in a standard way,
    returning a copy of a status block to the user.
        RESTRICT - produces a new restricted capability, which
    consists of standard modifications to the access rights bits.
    All servers that use the standard server side authentication
    algorithm may use a standard implementation of this.

        The following operations need a implementation based on
    the object:
        COPY - it duplicates the object, not only returns a
    capability for the copy; as such, its implementation depends
    on the object implementation.
        DESTROY - reclaims the object's storage space;
        INFO - different kinds of information may be returned
    for different objects; if a string with a predetermined
    maximum size is used to store this information, this
    operation could be implemented in a standard way, but only
    for servers that use a standard object table format.