[tahoe-dev] Tahoe Access Control

[Brandon Meskimen]

I would like to stay away from the HTTP Proxy server because if i understand
correctly, whoever has control of the HTTP Proxiy could leak that
information. I would like to keep the more complex file properties like who
access it (already has), when it was created(already has), and most
importantly, how many people have access to that file.

Regards,
Brandon

On Wed, Jun 1, 2011 at 2:56 PM, Zooko O'Whielacronx <zooko at zooko.com> wrote:

> On Wed, Jun 1, 2011 at 8:03 AM, Brandon Meskimen
> <brandon.meskimen at gmail.com> wrote:
> >         Is it possilbe to modify the mutable and immutable files access
> > control to be more complex? Is it possible to give one person permission
> to
> > access the file but not others if multiple people use the same account?
>
> You could run an HTTP proxy (using twistd, nginx, apache, or some
> other such tools) which requires the user to login (using standard
> authentication mechanisms such as name-and-password or oauth or
> something), and which has logic in it that gives the user back the
> file they asked for only if they meet your chosen criteria.
>
> >  Once that permission is given can you remove? Is it possible to have a
> more
> > properties per file when it is uploaded like who accessed it, i know it
> > already has last modified. Can you generate a different password so that
> the
> > person viewing the one file doesn't have control of access control change
> so
> > that it a person can have read, read/write, read/write/delete.
>
> All of this is possible in your HTTP proxy. Rejoice!
>
> Of course, if the first person who downloaded the file through your
> HTTP proxy shares a copy of that file with the second person, then
> this would evade your proxy's rules about who is allowed to see it.
> Also the fact that the second person viewed it would not appear in
> your proxy's "who has viewed this file?" statistics.
>
> Also, the first person might give their name and password to the
> second person, which would also defeat your scheme.
>
> On the other hand, maybe your scheme doesn't *have* to prevent those
> sorts of behaviors in order to be useful. Why not try it out and see?
>
> What is this for, anyway? Homework? :-)
>
> Regards,
>
> Zooko
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110605/c8bfbff5/attachment.html>