Project 3 -- Files, Directories, and Permissions

Due Tuesday, November 18

(Note that due date is later than originally listed in the class schedule.)

NOTE: This assignment, like the other projects in this class, is due at the beginning of the class period. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your homework ahead of time. Do this by submitting them electronically then giving the hard copy to me or the TA during office hours or by sliding it under my office door within twenty-four hours after the time it is due. Do not send assignments to me through email or leave them in my departmental mail box.

As discussed in class, the original UNIX permissions system based on "user," "group," and "others" is simple but inflexible. In contrast, the various Access Control List (ACL) mechanisms that have been tacked-on to various UNIX versions are flexible but unwieldy. One problem is that the normal directory listing mechanism (ls) is not only a stand-alone program in the UNIX system software (e.g., /bin/ls) but is also a built-in function in many shells. This is done for speed (no need for the shell for fork then exec the /bin/ls code) but means that many shells do not even hint to the user that the file has an ACL, much less give the user useful information about the ACL, when he or she uses ls.

One application that people might find useful is one that assists them in maintaining the ACLs on their files. This program could find and modify the ACLs for a user, adding or removing ACL entries based on available information regarding the file.



The Assignment

For this assignment, we'll implement a simple ACL maintenance program that we'll call ACLUpdate. Users will run ACLUpdate in one of two modes: (1) find and (2) modify.


For find, a user will type:

    ACLUpdate <directory>
where <directory> is the path name (either absolute or relative) for the directory that the user wishes to search for ACLs.

When started in find mode, ACLUpdate will search through the directory specified and find all files with ACLs. It will print to standard out the names of these files and the contents of their ACLs in the format specified on the getfacl manual pages. A line, consisting of 10 minus signs (i.e., "----------") will be printed between each set of file data printed.

If no files in the specified directory have ACLs, ACLUpdate will print the message "No files with ACLs in this directory."

Optionally, the user may specify the "-R" flag on the command line for ACLUpdate. If he or she does so, ACLUpdate will recursively descend into every directory below the specified directory and print information on all files in that directory as above. At the start of each new directory (including the one specified by the user) ACLUpdate will print the full path of the current directory on a line by itself. At the end of each new directory (including the one specified by the user) ACLUpdate will print a line consisting of 20 minus signs (i.e., "====================").

Optionally, the user may specify the "-L" flag along with the "-R" flag. In this case, ACLUpdate should follow soft links to files and directories. Otherwise, it should not.


For modify, a user will type:

   
    ACLUpdate <directory> -M <setfacl flags> <setfacl acl_entries> <basis>
where <directory> is the path name (either absolute or relative) for the directory that the user wishes to modify ACLs, <setfacl flags> and <setfacl acl_entries> are flags and entry information as specified in the setfacl manual pages, and <basis> is the basis on which the decision will be made to modify a file's ACL.

For a production version of ACLUpdate, we would probably want the basis of the decision to be arbitrary information regarding the file. To simplify your assignment, we'll only consider two: group ownership and modification time.

For group ownership, ACLUpdate will check to see if a file's group owner is equal to the group name given as <basis>. If the group owner for the file matches <basis>, the ACL will be updated as indicated by <setfacl flags> and <setfacl acl_entries>. (E.g., if <basis> is group123, then files with the group owner of group123 will have their ACLs modified.) Otherwise, the file's ACL will be unchanged.

For modification, ACLUpdate will check to see if a file's last time of modification is newer than the value given in <basis> considered as seconds. (E.g., if <basis> is 604800, then files modified within the last week will have their ACLs modified.) Otherwise, the file's ACL will be unchanged.

After modification, ACLUpdate will print the current ACL for the file, as described for find mode.

As with find mode, the user may optionally specify the -R and -L flags, which will make ACLUpdate recursively modify ACLs of all files in sub-directories of the directory specified, as with find mode, as described above.




Notes on this assignment

Some parts of the assignment above may be vague or incomplete. This is intentional. This is to give you experience with the way software development is done in "the real world" (industry, academia outside the classroom, government labs, etc.). Often you will get problem descriptions that are vague or incomplete, even if they seem concrete and complete initially.

You should read through the assignment carefully, look for ambiguities or cases not covered, then ask about them, either in office hours or through email, as soon as you can. (Recall that those people who come to office hours get priority over those who call during office hours who, in turn, get priority over those who send email.) If you wait until the last minute to ask about ambiguities or missing cases, you may not get an answer before your project is due. If you don't get an answer in time (or at all, if you don't ask), then you will have to guess how to handle certain situations. If you guess wrong, you will lose points.



What to turn in.

You will turn in both a hard copy and an electronic copy of your assignment. Please follow the instructions on how to send electronic copies. Do not send them to my email address.

Both the hard copy and the electronic copy will contain a write-up and all source code you used in this project. The electronic copy will also contain the executable version of your code. The electronic copy of your write-up should not be in a proprietary format (such as MS Word); it should be either in plain ASCII text or in a portable format (such as Postscript or PDF). Your source code should be in a single file called ACLUpdate.c and your executable code should be called ACLUpdate.

Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks).

Your write-up will include 1/2 to 1 page (roughly 80 characters per line, 50 lines per page) explaining the data structures and algorithms used in your code. This page limitation does not include figures used in your explanation, which are encouraged and may take up any amount of space. (This explanation does not remove the requirement that your code be well commented.)



Other

You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.

As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your write-up, including the names and student ID numbers of everyone involved.

Each group member is required to contribute equally to each project, as far as is possible. You must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, both your write-up and the comments in your code must clearly indicate this division of labor.