A shell script has been defined on the tartarus machines, which will define a subdirectory named minix, and populate it with the material for this assignment. To run the script, simply type ~cg411/minixsetup

What you will see will be symbolic links to the cg411 accounts directories, to optimize disk usage. There is no need for multiple copies of the 16 Megabyte disk images.

The MINIX File System

• The boot block contains some initial executable code for when the machine is first turned on.
• The super-block describes the allocation of the rest of the disk. It contains the following fields in sequence:
  • (2 bytes) The number of inodes defined
  • (2 bytes) The number of cluster allocated (V1)
  • (2 bytes) The number of disk blocks used for i-node bit map
  • (2 bytes) The number of disk blocks used for cluster bit map
  • (2 bytes) Block number for the first data cluster
  • (2 bytes) Binary logarithm of the number of blocks per cluster
  • (4 bytes) The maximum file size allocatable
  • (2 bytes) A "magic" number identifying the super block
                        137F Hex identifies Version 1; 2468 identifies Version 2
  • (2 bytes) -- empty padding --
  • (4 bytes) The number of clusters allocated (V2)
• The i-node and cluster bitmaps indicate which are allocated.
• The i-node blocks appear next, containing 64-byte inodes:
  • ( 2 bytes) The file mode (type and rwx), as in Unix (see Table 12.4)
    The items listed in parentheses in that table correspond to bits 15-12.
  • ( 2 bytes) Number of directory links that point to this file
  • ( 4 bytes) User ID and Group ID for owner of the file
  • ( 4 bytes) The number of bytes in the file
  • (12 bytes) Time of last access, last modification, and last change in status, counting seconds since 1/1/1970.
  • (28 bytes) 7 direct indexes to data blocks (4 bytes each)
  • (12 bytes) Indirect index pointers, as in Unix (4 bytes each)
  NOTE: The first i-node here is #1, not #0.
• The data blocks contain all the files, and anything else not listed above.

Documentation for the Solaris Port for Minix

ghostview ~cg411/doc/smx_ps	Describes the overall system. Pages 1-2 and 5-6 would be most useful.
ghostview ~cg411/doc/smx_lab_ps	Provides a simple tutorial for running this system.

This assignment will NOT involve making any changes to the Minix operating system code, so most of the documentation is irrelevant. Therefore, printing the complete documentation would only be a waste of time, paper, and your print quota. If you must have it on paper, ghostview will let you select which pages you want to print.

One possibly confusing difference between the Minix shell and our Solaris is how to logout. Minix uses the classical Control-D to logout, not the command 'logout'. (The curious can see what Control-D does on our system.)

Log in to your copy of Minix as described in the lab document. First log in as root, but to create a new user, do NOT go through the listed steps. Just use the 'adduser' script (for more info, type man adduser in Minix).

Then log in as this new user, and do the following:

1. Set the new user's password, using 'passwd'.
2. Create a file with any name: you have various ways to do so:
   • Use the elvis editor (a 'vi' emulator)
   • Use the 'echo' command, redirecting results to a file.
   • Use the 'cat' command with no parameters, redirecting results to a file. This will accept input from the keyboard up to the next Control-D.
3. In fact, create three or four files while you are at it, with readily distinguishable contents.
4. Give one of your files a name beginning with a period (.)
5. Create extra hard links to two of your files, using ln.
6. Compare the results of 'ls' and 'ls -a'. Contrast the differences here with what happens when you do the same thing in your Solaris root directory.

You don't have to report on any of this. This is just to get things going, and that last point is for your own thing to think about.

In fact, while you're there, or next time you log in, type "ps -alx", and (using the man page for ps) figure out what it means.

The Actual Assignment

Your job is to find the answers to all the items listed below. It is expected that you will write a program (in Solaris) to assist you -- since examining a binary image file is not a very natural activity for an end user. There is an expectation that everyone has at some point written a program that can read a file.

You can read The Minix disk images using the system library functions fopen, fseek, and fread. Information on these functions is available on the man pages. Note that this last one is designed to allow for a very simple way to read one or more records from a file, by defining the size of the record and the number of records desired. Many of you will find this much easier to use than making sense of individual bytes.

Unix does provide the octal dump (od) command to help you locate the information in these disk images, but since it does not produce very legible results, it should only be used as a way to get your bearings.

1. There are three disks in our Minix environment, one for /usr/bin, one for /usr/man, and one for everything else. Using the data in the superblock (and nowhere else), ind the following information for each of the three disks:
   1. The number of data blocks per cluster
   2. The total number of blocks on the disk
   3. The number of disk blocks that will hold i-nodes
      There are two ways to determine this value -- find them both.
   4. The maximum file size supported on this disk
      Show a calculation that results the maximum file size shown, and try to explain what it.

2. Find the first eight i-nodes on the man disk, and identify the following information:
   1. The file type and access protection for this inode
   2. The number of bytes in the file
   3. The last time the file was modified (use the C library functions listed in man -s3c ctime)
   4. A list of all the blocks allocated for the file, by block number.

3. List the entries in the root directory and /usr/man/man7. For each entry, list the file name, the inode reference number, and the size of the file (stored in the file's inode). It is up to you to figure out how a directory entry is represented -- but you may know that all entries occupy 16 bytes.

   Of all the entries in /usr/bin, list those (all and only those) whose inode indicates there is more than one reference. Why does .. have as many as it does?
   Identify all the filenames that use the same inode as bin commands cp, more and passwd. Verify that the number of references is correct. Note that many of the commands that overlap with cp use the same identical parameter list. How can the program know which command you requested?

4. Find the directory file for the new user you created. List all entries in this directory, including the following for each:
   • the file name
   • the number of the inode for this file
   • the number of references to this file
   • the numeric values of the owner id and group id
   • the number of the first data block for this file
   • the contents of that first data block

5. Login as the user again. Remove (rm) one of the linked files, without removing its link; and remove the other linked file, along with all links. Then, (via Solaris) examine the directory file again. Be sure to use the file size in the inode to determine how big the directory file is, and also be sure to display and describe ALL nonzero bytes in the directory file. Also inspect the corresponding inodes and file blocks that were noted before.

   What happened to the inode and file block for the file for which you deleted one reference? What happened to the inode and file block for the file for which you deleted all references?

6. Examine the entire directory for /usr/guest. You should be able to ascribe meaning to every entry in that directory.

7. For the following files, display (1) the file mode in octal (base 8), (2) the group id and user id as names, (3) the access rights to the file (who can read, etc.) (4) an explanation of every other nonzero bit in the file mode. Do so for /etc/shadow, /etc/passwd, /etc/group and /usr/bin/passwd. (Some of your necessary data will be in stored in the /etc files.)

   Verify your answer by logging in as your user on Minix, and typing ls -l for all those files. What does the s mean in the answer given for /usr/bin/passwd?

   Given this protection scheme, what information about users is publically accessible to other users on the system? What additional information would be made available if the protected files were somehow made available? In particular, is the password salt value visible? (You may have to consult some of the Minix man pages to answer that).

What to Hand In

No program code will be expected for this assignment. It is expected that many of the questions would be extremely awkward to answer without a program, and the purpose is to better understand the file system itself.

Therefore, only collect together your answers for each of the points listed under The Actual Assignment. Be sure to keep the steps clearly separate and numbered for ease of grading.