Introduction
第二部分的作业，主要是共享和取消共享，需要实现共享链，比如Alice共享文件A给Bob，Bob也可以共享文件A给Carol。当Alice取消共享给Bob的文件A时，也会自动取消Bob共享给Carol的文件A。此外需要考虑各种各样的攻击，跑过包括上一次在内的全部测试集。
Part 2: Adding complex features
Question 2 Sharing
A file store becomes much more interesting when you can use it to share files
with your collaborators. Implement the sharing functionality by implementing
the methods share() and receive_share().
When Alice wants to share a file with Bob, she will call msg =
alice.share(“bob”, filename). Alice will then pass Bob msg through an out-of-
band channel (e.g., via email). You may not assume that this channel is
secure. A man-in-the-middle might receive or modify the message after Alice
sends it but before Bob receives it. After this, if Bob wishes to accept the
file, he will call bob.receive share(“alice”, newfilename, msg). Bob should
now be able to access Alice’s file under the name newfilename. In other words,
Alice accesses the file under the name filename; Bob accesses it using the
name newfilename.
You can only send one message, msg, and it will be sent only once. msg must be
a string in python. During grading, we will pass this message from one client
to another on your behalf.
Property 3 (Sharing)
After m = a.share(“b”, n1); b.receive share(“a”, n2, m), user b should now
have access to file n1 under the name n2. Every user who this file has been
shared with (including the owner) should see any updates made to this file
immediately. To user b, it should be as if this file was created by him: he
should be able to read, modify, or re-share this file.
This also changes Property 1 and Property 2 from above. A download() operation
should return the last value written by anyone with access to the file (the
owner, or anyone with whom the file was shared). Only those with access to the
file should be able to read or modify it.
Sharing is tricky. Note that both filenames refer to the same underlying file,
and any writes performed by anyone who has access to the file should be
immediately visible to all other users with access to the file. Sharing should
be transitive. If Alice shares a file with Bob who shares it with Carol, any
changes to this file by any of the three should be visible to all three
immediately. Sharing a file with someone who has already received it results
in unspecified behavior (you may do whatever you choose). It is okay if the
storage server learns which other users you have shared a file with.
We require a minimal amount of efficiency: assuming a file (of size m) is
shared with n users, and Alice shares the file with a new user, you may
perform a linear (in n + m) number of either public or private key encryption
operations. This is simple to achieve: any reasonable scheme should be at
least this efficient. It is possible to do significantly better—and you are
free to do so if you choose—but we will not evaluate you on this.
Your client may only keep state for performance reasons. Your implementation
must work if your client is restarted in between every operation. Any state
maintained on your client must be able to be reconstructed from data that
exists on the server. Your clients may not directly communicate with each
other.
Again, you do not need to worry about rollback attacks with sharing. The
server may rollback state and remove a client from receiving updates. However,
this should only be possible if it is a complete reset to an old state.
Question 3 Efficient Updates
For this question, you must efficiently handle very large files—potentially
multiple gigabytes long. Design and implement a solution for efficiently
updating files that are already stored on the server.
This makes maintaining confidentiality and integrity much more difficult. Be
aware that when the server is malicious, it can perform arbitrary actions at
arbitrary points in time during your execution. For example, you cannot assume
that two consecutive calls to server.get(f) will return the same value.
You do not need to handle the case where two valid users are interacting with
the server simultaneously: you can assume only one user will interact with the
server at any point in time. (That is, you do not need to worry about
implementing locking.)
The requirements are exactly the same as Question 1, except that now we want
your solution to be efficient when making a small update to a large file.
By efficiency, we are referring the amount of data that must be transferred
over the network connection to the storage server. By “update”, we are
referring to the case where the user invokes upload(f, v2) on a file f that
was previously uploaded and whose previous contents were v1. Your solution
only needs to be efficient for updates that replace some bytes of the file in
place.
Question 4 Revocation
Remote collaboration is a difficult thing, and, unfortunately, one of your
collaborators has betrayed you, and you can no longer trust them. You realize
that you need to revoke their access to your files. Implement the revoke()
method, which allows a user to revoke someone else’s access to a given file.
You can’t stop them from remembering whatever they’ve already learned or
keeping a copy of anything they’ve previously downloaded, but you can stop
them from learning any new information about updates to this file.
Only the user who initially created the file may call revoke().
Property 4 (Revocation)
After calling revoke(otheruser, name), otheruser should not be able to observe
new updates to name, and anyone with whom otheruser shared this file should
also be revoked. Except for knowing the previous contents of name, to
otheruser, it should be as if he never had received the file.
This single property has several hidden implications which may not be clear
right away.
Suppose that in the past, Alice granted Bob access to file F, and now Alice
revokes Bob’s access. Then we want all the following to be true subsequently:
- Bob should not be able to update F,
- Bob should not be able to read the updated contents of F (for any updates that happen after Bob’s access was revoked), and
- If Bob shared the file with Carol, Carol should also not be able to read or update F.
You may not send any messages during revocation
You only need to implement functionality to revoke access from direct
children. If Alice shares a file with Bob, and Bob shares the file with Carol,
you are not required to allow Alice to revoke Carol’s access. It must work for
Alice to revoke Bob’s access.
If Alice shares a file with Bob, and Bob shares the file with Carol, you don’t
need to provide a way for Bob to revoke Carol’s access. We will not test this
situation: you only need to ensure that the original creator of the file can
revoke others.
If Alice shares a file with Bob, and then revokes Bob’s access, it may still
be possible for Bob to mount a denial of service (DoS) attack on Alice’s file
(by overwriting it with all 0s, or deleting ids), but Alice should never
accept any changes Bob makes as valid. She should always either raise an
IntegrityError, or return None (if Bob deleted her files).
Summary
Part2部分简直是噩梦，由于Share和Revoke的存在，Part1部分的代码几乎重写了。
