Re: Milestone 2: authentication and authorization

Greg Hudson wrote:

>> I'm thinking of some table indexed by path, then revision number,
>> with some nice, meaningful ordering to allow range searches...
>
>
> I had this idea too. However, it means when you copy a file it
> doesn't necessarily start out with the same permissions for others,
> which could be a least-surprise security issue in some cases.

I think it's only a matter of having the copy inherit the source's
permissions.

> I've been wondering whether there is a qualitive difference between
> the proper management of read permission versus write permission, and
> whether our system should reflect that. If you want to restrict read
> access to a resource, it is because the data itself is private. If
> you want to restrict write access to a resource, it is because the
> location is important; you don't particularly care if someone makes a
> modified copy of the data at some other location. Also, you're much
> more likely to want to make a repository world-readable by default
> than to make it world-writable by default.

I'd like to point out that having write permission does not necessarily
imply that you're allowed to copy. I know that's how Unix permissions
work, but I'm not convinced that we should mimick that behaviour.

> So, we could implement read access with properties (although it still
> needs to be possible to retroactively restrict a particular
> node-revision, which is a problem for our conception of properties)
> and write access with a table, maybe. I'm completely unsure that we
> want to make the split, but it's an interesting idea.

Brrrr, I wouldn't want to maintain that /or/ write documentation for it! :-)

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/