On 01/06/11 18:52, Greg Troxel wrote: > toby cabot <[email protected]> writes: > >> If I give someone a URL to a directory can I later revoke that URL >> somehow but still be able to access the directory myself? > > No. But you can move the files in it to a new directory and hope the > original directory gets garbage collected. > > But again, if they copied the data, you can't revoke that. > > > It's interesting that this comes up in tahoe much more so than in other > filesystems. People don't seem to ask: > > if I have a filesystem, and I let someone read a file, and then I > "chmod 700" it, how can I be sure they didn't keep a copy? Isn't it a > bug that the filesystem doesn't enforce removing all their copies? > > about other filesystems.
Nor do they ask about the revocation behaviour of Unix file descriptors
or Windows HANDLEs (which in fact is very much like capabilities; in
particular, access is checked only on open [*]).
Perhaps they assume that an attacker can't be running a program on the
same machine, or perhaps they don't trust the Unix or Windows access
control models at all. Still, it's odd that pure capability systems are
criticised for a perceived weakness that is routinely ignored in ACL
systems that have some capability-like abstractions.
[*] For example, on Linux:
python
>>> f = open("test", "wb")
>>> f.flush() # make sure the file exists
>>> import os
>>> os.chmod("test", 0400) # could be done by another process or user
>>> open("test", "wb")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied: 'test'
>>> f.write("abc") # write succeeds on already-open fd
>>> f.close()
>>> open("test", "rb").read()
'abc'
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
