Assignment 7, Solutions

The i-node in question has 10 direct addresses of 4 bytes each, and all disk blocks are 1024 KB (odd, possibly a typo!); in the figure, the final disk address is used as the address of a block holding the addresses of the next blocks in the file.

The typo plus the ambiguous wording require that the student be very careful to state the assumptions made. The answer given here assumes the following:
A) KB is a typo, B was intended.
B) The 10 direct addresses do not include the an indirect pointer.

So, we have 10x1024 or 10240 bytes of capacity through the direct address pointers, plus what is reachable from the indirect pointer. Assume that points to a block of 256 4-byte pointers, allowing 256x1024 or 262,144 bytes. Add these to get 272,384 bytes as the maximum file size.

Do problem 18 on page 450.

There are 8 direct pointers plus 1 indirect pointer in the i-node in Figure 6-15. This allows 9x4 or 36 bytes to be stored in an ultra-small file within the i-node. Therefore, if the file-size file attribute is under 36, we can code things so the data is within the i-node itself.

Do problem 19 on page 450. (Hint: are there semantic consequences?)

Carolyn may be right about efficiency, but Elinor has noticed that the Carolyn's implementation will have a different semantics than people expect. Specifically, if two users open the same file using copies of the I-node, and then one of them makes a change (extending the file size by one byte, for example), since this is recorded in the file attributes field of the I-node, the other user will not see this change!

Do problem 27 on page 451.

Keeping the i-node and the first part of a file on the same disk block would mean that, on reading the i-node, the first part of the file would already be in the sector-cache maintained by the system, so no additional disk I/O would be required to read or write the first part of the file. In fact, this is merely another way of talking about the same issue as was discussed in problem 19!

Do problem 37 on page 452.

To open /usr/ast/courses/os/handout.t, assuming the root i-node is already resident, we do the following reads:
1: directory /
2: i-node for /usr
3: directory /usr
4: i-node for /usr/ast
5: directory /usr/ast
6: i-node for /usr/ast/courses
7: directory /usr/ast/courses
8: i-node for /usr/ast/courses/os/
: directory /usr/ast/courses/os/
10: i-node for /usr/ast/courses/os/handout.t

Note that, in addition to the assumptions Tannenbaum documented, we've also assumed that either there was no sector cache, or that none of the i-nodes were in the same disk block. If there had been a sector cache and two i-nodes were in the same block, we'd save a read!

To prevent a buffer overflow attack, make sure that the page beyond the buffer is marked as invalid or read-only in the MMU. Software trying to write beyond the end of the buffer will then cause a protection violation trap.

Do problem 15 on page 668.

A Trojan horse attack can work on a system protected by capabilities. The attack is possible if the unaudited software (containing the trojan) is executed in the same domain as its user. Only by creating a safe domain for the unaudited software can we secure it. The presence of capabilities does not imply that they have been used to create a safe domain!

Do problem 30 on page 669.

           | PPP-notes |    prog1   | project.t | splash.gif |
     ------+-----------+------------+-----------+------------+
     gmw   |   rw-     |    r-x     |    rw-    |            |
     ------+-----------+------------+-----------+------------+
     asw   |   r--     |    rwx     |    rw-    |    rw-     |
     ------+-----------+------------+-----------+------------+

     users |   r--     |            |    rw-    |            |
     ------+-----------+------------+-----------+------------+
     devel |           |    r-x     |           |    r--     |
     ------+-----------+------------+-----------+------------+

Note that the lines of the access matrix for the groups were only included so they could be merged with the access that each group member gets. The entry for each user is the result of merging the access that user earned as a member of the public with the rights they earned as owner and the rights from each group to which they may belong.

Do problem 31 on page 669.

             PPP-notes:  gmw/rw- asw/r--
             prog1:      gmw/r-x asw/rwx
             project.t:  gmw/rw- asw/rw-
             splash.gif: asw/rw-

Here, I've ignored the groups and included only the pure ACL for the users. ACL-based systems can be extended to include groups, but I've ignored this.

Do problem 32 on page 669.

The Unix scheme has a short ACL on each file, with only 3 entries, user, group and other. Therefore, any file where different users have 4 or more distinct sets of access rights suffices to break the system:

             PPP-notes:  gmw/rw- asw/r-- blt/--x bmw/r-x
             prog1:      gmw/r-x asw/rwx
             project.t:  gmw/rw- asw/rw-
             splash.gif: asw/rw-