Please mail me any problems with, or comments about this page.
PGP keys local copy
Homework must be submitted electronically to
<csci555@usc.edu>.
It should have a subject of “Homework
3.” You must submit plain text without
embedded formatting commands or markup (ASCII or UTF-8 are acceptable).
That means, among other things, no postscript, no Microsoft Word, no
PDF, no FrameMaker, no TeX, no groff, no DocBook, no HTML, no XML, and
no JavaDoc. Do not submit your homework as an attachment to your
e-mail. Do not base 64 encode it. Do not Rot13 encode it. Plain
text. You may PGP sign it, but are not required to do so. Do not PGP
encrypt it. If you submit something that is not unmarked-up text, it
is functionally the same as turning nothing in.
Homework turned in on the due date is not penalized, one day late is 25% off (that is the grade will be multiplied by 0.75), 2 days late is 50% off, and 3 days late is 75% off. No work will be accepted more than 3 days late. I will generally use the Date: line of the mail, but should the situation merit it, I am not above looking through mail system logs to confirm the submission time. I should not have to mention it, but forging a Date: line to avoid a late deduction is grounds for an F.
Do the work yourself. Computer science is a collaborative science, and I encourage you to talk over the ideas in the homework with other students. However, the final submission, that is, the text of the homework, must be composed individually by each student. If you hand in homework that is identical to another student, you risk failing the class. (In fact the only way that you would not fail the class in such a circumstance would be if one student had copied another student without the knowledge of the copied student; the copied student would not be penalized.) That is an awfully large risk for 10% of your total grade. Do the work yourself.
As with all work for csci555, this work is subject to the USC code of Student Conduct. Read it, learn it, live it. Should you have any questions on how to apply the code, do not hesitate to contact me or the Office of Student Judicial Affairs and Community Standards. Should it prove possible, do not plagiarize work from sources outside the class. Plagiarizing homework is grounds for failing the class. It is perfectly all right to properly cite external sources, should you find some that are useful.
Answers will not be graded on their beauty of expression. Answers will be graded on whether they show a logical approach and sensible explanation. Short, simple sentences are fine. What is important is that your ideas are clear to the reader, and that they answer the question. Of course, no answer will be penalized because it is beautifully expressed, either.
Each question has equal weight.
1. | Flask[Spencer99] describes a system where access control can be based on multiple facts about users and objects (e.g., files). For example, a file might be accessible to members of a given department and auditors, or to members of a department who are not supervisors. In most cases these kinds of permissions can be represented by traditional group-based file permissions, even if it is unwieldy. Explain how one can represent the example where all members of a department and auditors can read a given file. You can assume department members share a group and auditors do as well, and that you can create new groups. (3 points) Given that it is possible to represent those permissions, explain why label-based access control, like Flask, is better when complex permissions like the above are in use. Include an example to make your point. (7 points) |
2. | Many of the file system designs we discussed, including the Log-structured File system[Rosenblum91] and Soft-Updates[McKusick99] are based on using CPU and memory resources to compensate for the limitations of a storage system. What differences in file system design would you expect if the physical limitations on storage latency disappeared? Give a principle such a design would follow and a specific, practical difference in implementation. |
3. | Many papers we discussed this semester used microbenchmarks, which are simple performance evaluations, to assess the performance of their systems. Examples of microbenchmarks include the Create, Read, Write, Delete benchmarks in the LFS performance analysis paper[Seltzer95]. Explain why microbenchmark figures are not always accurate estimates of application performance. (5 points) How you think microbenchmarks should be used in assessing system performance? Support your position. (5 points) |
4. | The microkernel implementations we discussed generally did not implement a unified access control system, and for those that did, there's no requirement that all servers use the same access control system. Explain one advantage and one disadvantage of that state of affairs. (5 points each) |
[Spencer99] “The Flask Security Architecture: System Support for Diverse Security Policies,” The Eighth USENIX Security Symposium, USENIX, August 1999, 123-139,
[Rosenblum91] “The design and implementation of a log-structured file system,” 13th Symposium on Operating Systems Principles, ACM, October 1991, 1-15,
[McKusick99] “Soft Updates: A Technique for Eliminating Most Synchronous Writes in the Fast Filesystem,” FreeNIX Track: 1999 USENIX Annual Technical Conference, USENIX, June 1999, ,
[Seltzer95] “File System Logging Versus Clustering: A Performance Comparison,” USENIX Conference, January 1995, ,