monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Wim Oudshoorn
Subject: [Monotone-devel] Re: new default get_netsync_*_permitted hooks
Date: Sun, 23 Oct 2005 21:40:30 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin)

Timothy  Brownawell <address@hidden> writes:

> Hi,
>
> The get_netsync_*_permitted hooks now have default definitions, which
> read $confdir/{read,write}-permissions .
>
> write-permissions is a list of allowed keys, one per line, with
> "--all--" meaning to allow access to everyone whose pubkey we have,
> including anonymous readers.
>
> read-permissions looks like
>
> [net.example.project.security*]
> [net.example.project.private*]
> ! --all--
> address@hidden
> address@hidden
> [net.example.public*]
> [net.example.project*]
> --all--

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?  


> 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?

> 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

* Start with default deny all.

* 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.

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.

Wim Oudshoorn.

  

         






reply via email to

[Prev in Thread] Current Thread [Next in Thread]