Homework 6 Solutions

22C:116, Spring 1997

Ioana M. Lungeanu
Problem 1 part A:

    There are multiple solutions to this problem.  One is given:

    The root (superuser) creates the .password file in each user's
    home directory.  The root makes the user the owner of the
    .password file, with WR access rights to it.  There is a group
    containing one generic user, call it LOGIN.  The group of the
    .password file is set to LOGIN with R access on it.  The
    user-authentication program (login) runs in the name of this
    LOGIN group.

    file            owner           group           rights

    user_home_dir   user            -               RWX/---/R-X
    .passward       user            LOGIN           RW-/R--/---
    login           LOGIN           -               RWX/---/---

    User_authentication_program may reside, for example in /bin.

    Note that if the user makes his .password file publically
    readable, security may still rest on cryptographic protection
    of the password.  If the user makes his .password file publically
    writable, security is lost.  Users should not do this, and the
    chmod program could be modified to guard against this mistake.
    If the user deletes or renames the .password file, the login
    program would be unable to function, so again, the rm and mv
    commands should guard against this mistake.  Typically, such
    guards would be in the form of a message "Do you really want
    to do this? (Y/N):"

Problem 1 part B:

    The association between a user and the numerical user and
    group IDs is central to system security, so it should not be
    possible for anyone to modify this other than the superuser.
    Placing this in /etc/login, as in current UNIX systems (or in
    something similar, writable only by the system) would make
    perfectly good sense.

        Disclosure of user and group id's causes no problems,
        so this file can be publically readable.  Allowing
        anyone but the system to set them could allow some user
        to masquerade as some other user.

    For the sake of efficient computation, it should be easy for
    the login program to map from login name to home directory,
    so including this in some place like the /etc/login file makes
    sense.  In fact, allowing users to change their login name
    would be possible, so long as users could not select a name
    used by someone else.

        Public disclosure of user login names causes no problems,
        other than allowing users to become the target of junk

    The user's preferred shell could be put in the user's personal
    .login file -- it is clearly not needed by other users and
    should be easy for the user to change when needed.

        Public disclosure of a user's preferred shell is never
        needed but causes no problems.  Nobody but the user
        should be able to change their preferred shell.  If the
        user selects a non-functional shell, it is the user's
        fault.  The passwd program (or whatever tool the user
        uses for editing the .login file) should provide some
        degree of protection against setting an invalid preferred

    Directory information currently in the .login file (office
    address, phone numbers, etc) can be easily moved to publically
    readable files akin to the .plan and .project files.

        Disclosure of this information should be at the user's

Problem 2

    Transmitting Process

        To send a 1, do some CPU-bounded computation for a predefined
        period of time.  One way to measure the time is using the
        system calls alarm() and signal().  The parameter taken by
        alarm specifies an interval in seconds, after which a SIGALARM
        signal is send to the process announcing that the desired time
        has ellapsed.  The same can be done using the time() system

        To send a 0, wait doing nothing (don't use CPU time) for the
        same time interval.  The system call needed is pause() or
        sleep().  Pause() tells Unix to suspend the process until the
        next signal arrives, and thus is used in conjecture with the
        time measuring system calls from above.  Sleep() takes as
        parameter a time period (and is implemented using pause() and

    Receiving Process

        There can be a few ways of monitorizing the CPU activity.
        Whichever the way the receiver has to check in each interval
        of the predifened length in time for transmitting a bit.
        The receiver can, for example, do repeatedly a simple
        computation for the bit interval, and count the times it did
        it.  If it did the operations only a "few" number of times,
        the CPU must have been busy, and hence he interprets it as a
        1, otherwise is a 0.  We assume the noise is taken care of
        by other means.  The period of time it does each round is
        measured using the system calls mentioned above.

        There has to be gobal clock when they start this covert
        channel.  For example in the middle of the night when the
        systems are usually not so loaded, at a precise time.  Also
        they need to keep synchronized in their time interval by
        having the same "bit transmittion time" and 'identical'
        overheads. Maybe resinchronize periodically by having preset
        restarting points.

Problem 3

    Here is a reasonable hierarchy for UNIX file classes, with
    notes on what method each subclass adds to the parent's
    method set:

    file -- read()
        directory files -- lookup(name),link(name,file)
        non-directory files -- write()
            random-access files -- seek(), get-sector-size()
                block-device-drivers -- format()
                asynch-line -- set-baud-rate(), hangup()
                parallel-port -- check-paper-empty()
                sockets -- connect()

Problem 4

    One commonly suggested solution to break the deadlock is using
    timeouts.  One process waits for a message only a predefined
    limited period of time.  If the message doesn't arrive, the
    process simply ceases waiting for it and goes on to send out
    what ever it has to.

        In fact, timeouts are a deadlock detection method, and
        the timeout method described above only briefly mentions
        its solution to the deadlock resolution -- that of allowing
        unblocking the waiting process as if a message had been
        received; this is quite different from aborting it!

    Another solution would be to have the OS send a special message
    to a waiting process when a deadlock is detected.  From the
    point of view of deadlock resolution methods, this is exactly
    the same method suggested for use with timeouts -- unblock one
    or more of the deadlocked processes and allow it to continue,
    notifying it that the expected message did not arrive.