FAQ for HW4
Does [init-file] contains both user information as well as directory structure information?
No. The init-file stores information from infile. The file directory
structure will be stored in another file/directory in whatever format you
choose. Say you put this in a file called "states". Then when your server
starts for the first time and "states" is not present, the server should
interpret this appropriately. When some files are uploaded by clients and
then the server terminates, the state information should be stored in
"states". And then the next time the server starts, it can pull all that
information from that file.
Note that new clients might be added to the system (by changing [infile] and then running init again) without changing anything in the directory structure.
Can different files within the same directory have different clearances?
No. All files within a particular user's directory have the same clearance as that user. Note that
this corresonds to mandatory access control, rather than discretionary access control.
To access a file "/Bob/foo", does a user need to type, e.g., "more /Bob/foo"?
No. If the current working directory of a user is "/Bob" then typing "more foo" automatically refers to the file "/Bob/foo". In the sane case, typing "more /Alice/foo" then refers to the file "/Alice/foo". This is just like in unix.
Under what conditions can a user "cd" into another user's directory
This is for you to figure out. Explain your choice in your decument.
Can we change the command line input of the server and/or client?
No. The TAs will run a grading script that expects the commands to be run as stated.
It should not be necessary to add other arguments at the command line. For example, if you wanted
the server to have a public key, this key can be hard-coded into the client software. If you want a client
to have a public key, you need to figure out a way to do this which relies on a password-based
mechanism only.
If you are unsure of something, do the best you can to meet the states requirements and then explain yourself in your document.
Do we need our protocol to be secure against server compromise?
You are not required to make your protocol secure against server compromise, but server compromise is always a threat. (Note that server compromise refers to an adversary who obtains long-term keying information stored on the server. It does not refer to adversarial modification of any data stored on the server, nor does it refer to an adversary compromising the server to read files stored on the server.)
In general, if you decide that you do not need to be concerned with a particular attack you should explain your decision in your design document.