Individual written problems are to be done individually. Group programming problems are to be done in your assigned programming groups. The deadline for group programming problems applies to both CVN and non-CVN students. All homework submissions are to be made via the submit programs. Refer to the homework policy page on the class web site for further details.

Non-Programming Problems:

1. Exercise 11.3

2. Exercise 11.6

3. Exercise 11.14

4. Exercise 11.19

5. Exercise 12.2

6. Exercise 13.2

7. Exercise 13.12

8. Exercise 13.16

9. (8 pts) Explain the purpose of the open and close operations. Describe what happens in the Linux 2.4.2 kernel when open is called. Be sure to list the procedures that are called and explain the function of each.

Programming Problems:

Programming problems are to be done in your assigned groups using the VM that has been assigned to your group. For all programming problems you will be required to submit source code, a README file documenting your files and code, and a test run of your programs. In addition, you should submit a cover sheet using either homework_work.txt or homework_nonwork.txt, depending on whether or not the programming assignment is completely working or not. For source code submissions, you only need to submit new source code files that you created and kernel source code files that you changed. You should clearly indicate your names, email addresses, and assigned group number on your submission. Each group is required to submit one writeup for the programming assignment.

The image of the kernel you build for this assignment should be vmlinuz.hmwk6. Grading for this assignment will be done based on vmlinuz.hmwk6. The kernel you use for this assignment should be the Linux 2.4.2 kernel you built and installed as part of Homework #2.

Background

The standard Unix filesystem permission scheme is very crude. It breaks the entire world into three parts: a file's owner, a file's group, and everything else. Each one of these parts has three bits signifying whether they can read, write, or execute a specific file. A sample file listing would be something like:

For this assignment, you are to implement a more flexible access control list scheme, where an additional set of permissions, for additional users and groups, are checked upon file access. This assignment will demonstrate Linux's filesystem behavior, show you how to access files from kernel-space, and teach you how to implement a commonly-used security method. Two references that you may find helpful are the Linux reference book for the course and and Chapter 9 of The Linux Kernel.

1. (25 pts) Implement a system call that takes a filename, a user-id, a permission set, and a mode. The specified user-id is then added to an access-control list, along with its permissions regarding this file. This permission set is checked ahead of the standard permission scheme (i.e. owner, group, other) whenever a file is opened for reading or writing, or executed. The prototype for this system call is: int acl_perms(char * filename, int id, int permission, int mode); permission should be some combination of the values 4 for read, 2 for write, and 1 for execute. If the value of mode is 1, that signifies that id is a user id (a uid). If the value of mode is 2, that signifies that id represents a group id (a gid). modes of -1 and -2 specify that the identified user or group are to be removed from the access-control list.

   In order to make your changes persistent, the kernel is to save this infomation to a file named .acl within the directory in which your acl protected files reside. You can find out how to make system calls from kernel space in the article Making System Calls from Kernel Space.

2. (20 pts)Modify the kernel so all appropriate file accesses check these permissions from the correct .acl file (if one exists). The user-ids in the acl list are the first permissions checked. If they either grant or deny access to the user seeking file access, then their decision is final. Next, the group-ids are checked. If they do not provide an answer, the default linux permissioning scheme has the final word. Your acl implementation need not be portable; it only needs to work for the ext2 filesystem.

3. (10 pts)Add to the system three users with ids of 501, 502, and 503. Through a test program, have each one granted read, write and execute permissions respectively for a specific file. Demonstrate that each process only has its specified permissions. Repeat this procedure with different group ids.

4. (5 pts)What is one way that a user can bypass the protection provided by this ACL implementation? Explain how you would change the design to close this loop hole without adversely impacting the efficiently of the overall implementation.

Additional Notes:
Your solution only applies to files and not directories. All directory access should occur through the default methods. Note that a dentry list exists that consists of several different pointers to one inode. Each dentry is a representation of that inode in a different directory. It is important that you ignore this list because 1) it is problematic code to begin with and 2) it is only representative of directories that have been recently accessed - other "dormant" directories might be excluded from this list.