Re: [Monotone-devel] Re: new default get_netsync_*_permitted hooks

[Timothy Brownawell]

On Sun, 2005-10-23 at 21:40 +0200, Wim Oudshoorn wrote:
> Not sure if this is the right format.  It confuses me enormously.
> For example, how does this work
> [pattern1]
> [pattern2]
> key1
> [pattern3]
> key2
> 
> Does key2 have access to pattern1 and pattern2?  Or is the pattern
> list reset after encountering a key? Or is it reset after an empty line?
> what about comment lines?  

key2 has access to pattern3. It will only have access to pattern1 and
pattern2 if they are subsets of pattern3. The file is considered to be
in "blocks", which are one or more "[wildcard]" lines followed by one or
more other lines, and matching blocks are processed independently and in
order until a match (including "--all--") or "! --all--" is found, or
EOF. And I actually didn't think to make it support comments.

> > where [something] is a wildcard that's matched against the branch.
> > "! key" means deny access, "--all--" means allow everyone access, and
> > "! --all--" means to stop looking if the key isn't mentioned in the
> > current section. More specific branch patterns should be at the top, if
> > there's a "[*]" it should be the last entry.
> 
> Also, in the example you gave,
> it seems that the last rule:
> 
> [net.example.project*]
> 
> overrules the access permissins for
> 
> [net.example.project.securitey*]
> [net.example.project.private*]
> 
> But on a more carefull reading of your explanation indeed it does not.
> However I you would remove the line !--all-- 
> on the first section I assume that everyone has read access, right?

Not overrules. If permission is specifically given or denied, then
that's that. If permissions are not specified, then it will fall through
to the next section that matches (unless "! --all--" is given).

> > Thoughts in general, or for a better format for read-permissions?
> 
> Not really, however I think I might prefer something like your scheme
> except that:
> 
> * you have only one branch pattern per rule set,
>   that is, don't use:
> 
>     [pattern1]
>     [pattern2]
>     rule
> 
>   I would not want multiple patterns because it is not clear
>   what happens in situations like:
> 
>     [pattern1]
> 
>     [pattern2]
>     rule
> 
>   Or
> 
>     [pattern1]
>     # this is a commented rule
>     [pattern2]
>     rule

I did it this way because (1) it was simpler to implement wildcard
matching than to implement full glob matching (would have to convert to
regex and call regex.search and do error catching) and (2) I figured it
would be useful for giving the same permissions to different patterns.
With full glob (or regex) matching this could be avoided, but that might
lead to unwieldly long things like {pattern1,pattern2} . Maybe this
would be uncommon and not so bad?

> * Start with default deny all.

It does. If there's no match found, it denies access.

> * Don't scan examine any rule set after the first match.  
>   That is:
> 
>      [pattern1]
>      address@hidden
> 
>      [*]
>      --all--
> 
>   Will not suddenly give --all-- permission to pattern1.

I thought it'd be useful to be able to refine permissions for more
specific branch patterns (add these users, remove these other ones)
without having to respecify everything. Perhaps there's a better way to
distinguish between "set permissions to exactly this" and "permissions
are like the parent branch's (or rather, next-most-specific matching
pattern's) permissions, except with these differences"? ("! --all--"
means "deny everyone who hasn't been permitted yet", or equivalently
"set permissions to exactly this")

> Finally, I don't think I like the syntax you propose.  
> Is this already used somewhare? 
> I think access control configuration is used in lots
> of places, so maybe there is already a thought out
> format for these kind of things.  
> But he, I am not an expert on this at all.

I don't think its great either, but I'm not sure what would be better.

Tim