new default get_netsync_*_permitted hooks

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

new default get_netsync_*_permitted hooks

Timothy  Brownawell
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--
[hidden email]
[hidden email]
[net.example.public*]
[net.example.project*]
--all--

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.

Thoughts in general, or for a better format for read-permissions?

Tim




_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Wim Oudshoorn
Timothy  Brownawell <[hidden email]> 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--
> [hidden email]
> [hidden email]
> [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]
     someone@somewhere

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

 

         




_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Richard Levitte - VMS Whacker
In reply to this post by Timothy Brownawell
In message <1130094163.22161.12.camel@localhost> on Sun, 23 Oct 2005 14:02:43 -0500, Timothy Brownawell <[hidden email]> said:

tbrownaw> The get_netsync_*_permitted hooks now have default
tbrownaw> definitions, which read $confdir/{read,write}-permissions .

Cool!

tbrownaw> read-permissions looks like
tbrownaw>
tbrownaw> [net.example.project.security*]
tbrownaw> [net.example.project.private*]
tbrownaw> ! --all--
tbrownaw> [hidden email]
tbrownaw> [hidden email]
tbrownaw> [net.example.public*]
tbrownaw> [net.example.project*]
tbrownaw> --all--
tbrownaw>
tbrownaw> where [something] is a wildcard that's matched against the
tbrownaw> branch.  "! key" means deny access, "--all--" means allow
tbrownaw> everyone access, and "! --all--" means to stop looking if
tbrownaw> the key isn't mentioned in the current section. More
tbrownaw> specific branch patterns should be at the top, if there's a
tbrownaw> "[*]" it should be the last entry.
tbrownaw>
tbrownaw> Thoughts in general, or for a better format for
tbrownaw> read-permissions?

Just a small variation: I think that as soon as a section that matches
the queried branch is found, the search for permissions should stop
there and only the permissions in that section should be considered.
The whole '! --all--' business is just confusing.  Your example would
also end up simpler:

 [net.example.project.security*]
 [net.example.project.private*]
 [hidden email]
 [hidden email]
 [net.example.public*]
 [net.example.project*]
 --all--

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis


_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: new default get_netsync_*_permitted hooks

Timothy  Brownawell
In reply to this post by Wim Oudshoorn
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]
>      someone@somewhere
>
>      [*]
>      --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




_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Daniel Carosone
In reply to this post by Timothy Brownawell
On Sun, Oct 23, 2005 at 02:02:43PM -0500, Timothy Brownawell wrote:
> The get_netsync_*_permitted hooks now have default definitions, which
> read $confdir/{read,write}-permissions .

Great!  Inspired by the .mt-ignore implementation, I was thinking of
doing something like this as an exercise in teaching myself lua.  

In general, there are a number of other hooks that could follow a
similar pattern. Often I want to add one or two more things to a
default list (after ignore, matching binary/text files is the example
that next springs to mind). It worries me that I have to find and copy
a default hook implementation, and then have it go out of date when
the default is updated.

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

As an aside, it still annoys me (I understand why it's the case) that
you can't give write permissions selective per branch.  However, this
argues that the semi-equivalent certificate trust hooks should take a
similar form to the permissions.. and crosses over the key trust
discussion in general.

Anyway..

> read-permissions looks like
>
> [net.example.project.security*]
> [net.example.project.private*]
> ! --all--
> [hidden email]
> [hidden email]
> [net.example.public*]
> [net.example.project*]
> --all--
>
> where [something] is a wildcard that's matched against the branch.
Sorry, but.. yuck :)

> "! 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.

This confuses me :-)

> Thoughts in general, or for a better format for read-permissions?

A simple table would be fine, in my view.  I can edit the file to
duplicate parts if needed:

net.example.project.security* DENY *
net.example.project.private*    READ [hidden email]
net.example.project.private*    READ [hidden email]
net.example.project* READ *

The first match for both branch and key applies the listed permission.
Keys are listed last to allow for spaces in the names.

There are a couple of reasons I was thinking along these lines.
Firstly, I'd like to see read and write permissions in the same
file/format, and perhaps others (as above). That means adding new PERM
keywords (and possibly listing that keyword first to allow the
'parameters' to vary for different perm types?)

Secondly, and more immediately for implementation purposes, I'd like
to see these kinds of hooks split into two parts: an initialisation
hook which reads these files into a lua table, and the current hook
which simply evaluates the already-loaded table (rather than rereading
the file on every evaluation).

Just like the ignore case, I can then easily keep the default list,
and just add some entries in a config file.  I could even have some in
~/.monotone/foo, and add some more checkout-specific ones in
MT/foo. Eventually, key trusts and other permissions embodied in
certificates in the database could also be part of populating this
table at initialisation.

--
Dan.
_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel

attachment0 (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Wim Oudshoorn
In reply to this post by Timothy Brownawell
Timothy  Brownawell <[hidden email]> writes:


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

Ah, this is a much clearer description.


> 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")

Generally speaking, for files that specify access control, I prefer
a simple and clear format.   A format that is even obvious when you do
not know the semantics.  So I rather respecify everything than being
clever and reuse settings.

In real life most access control lists use a format that is
too difficult for me ;-)

Wim Oudshoorn.



_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: new default get_netsync_*_permitted hooks

Timothy  Brownawell
In reply to this post by Timothy Brownawell
On Sun, 2005-10-23 at 15:46 -0500, Timothy Brownawell wrote:
> On Sun, 2005-10-23 at 21:40 +0200, Wim Oudshoorn wrote:
> > 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.

Random idea:


pattern "net.example.project.{security,private}*"
allow "[hidden email]"
allow "[hidden email]"

pattern "net.example.{public,project}*"
others "allow"


where others defaults to "deny" if not mentioned, and setting it to
"continue" or something means "look for other blocks that match the
branch we're checking permissions for".

Tim




_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: new default get_netsync_*_permitted hooks

Richard Levitte - VMS Whacker
In message <1130104879.22161.53.camel@localhost> on Sun, 23 Oct 2005 17:01:19 -0500, Timothy Brownawell <[hidden email]> said:

tbrownaw> On Sun, 2005-10-23 at 15:46 -0500, Timothy Brownawell wrote:
tbrownaw> > On Sun, 2005-10-23 at 21:40 +0200, Wim Oudshoorn wrote:
tbrownaw> > > Finally, I don't think I like the syntax you propose.  
tbrownaw> > > Is this already used somewhare?
tbrownaw> > > I think access control configuration is used in lots
tbrownaw> > > of places, so maybe there is already a thought out
tbrownaw> > > format for these kind of things.  
tbrownaw> > > But he, I am not an expert on this at all.
tbrownaw> >
tbrownaw> > I don't think its great either, but I'm not sure what would be better.
tbrownaw>
tbrownaw> Random idea:
tbrownaw>
tbrownaw>
tbrownaw> pattern "net.example.project.{security,private}*"
tbrownaw> allow "[hidden email]"
tbrownaw> allow "[hidden email]"
tbrownaw>
tbrownaw> pattern "net.example.{public,project}*"
tbrownaw> others "allow"

Random response:

I think it's quite confusing how the format is sometimes
'verb "subject"' and sometimes 'subject "verb"'.  I would rather have
some kind of consistency:

 pattern "net.example.project.{security,private}*"
 allow "[hidden email]"
 allow "[hidden email]"
 
 pattern "net.example.{public,project}*"
 allow "*"

Cheers,
Richard

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis


_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Nathaniel Smith
In reply to this post by Daniel Carosone
On Mon, Oct 24, 2005 at 06:59:44AM +1000, Daniel Carosone wrote:
> In general, there are a number of other hooks that could follow a
> similar pattern. Often I want to add one or two more things to a
> default list (after ignore, matching binary/text files is the example
> that next springs to mind). It worries me that I have to find and copy
> a default hook implementation, and then have it go out of date when
> the default is updated.

As a side note, there's a simple trick you can use for this sort of
thing, in lack of anything better ATM...:

# Add the .foo extension to the standard list of ignored files
default_ignore_file = ignore_file
function ignore_file(name)
  if (string.find(name, "%.foo$")) then return true end
  return default_ignore_file(name)
end

-- Nathaniel

--
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield

This email may be read aloud.


_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Daniel Carosone
On Sun, Oct 23, 2005 at 04:18:19PM -0700, Nathaniel Smith wrote:
> As a side note, there's a simple trick you can use for this sort of
> thing, in lack of anything better ATM...:
>
> default_ignore_file = ignore_file

Ahah. "cute". lua_clue++, thanks.

--
Dan.
_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel

attachment0 (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: new default get_netsync_*_permitted hooks

Timothy  Brownawell
In reply to this post by Richard Levitte - VMS Whacker
On Mon, 2005-10-24 at 01:16 +0200, Richard Levitte - VMS Whacker wrote:

> In message <1130104879.22161.53.camel@localhost> on Sun, 23 Oct 2005 17:01:19 -0500, Timothy Brownawell <[hidden email]> said:
>
> tbrownaw> On Sun, 2005-10-23 at 15:46 -0500, Timothy Brownawell wrote:
> tbrownaw> > On Sun, 2005-10-23 at 21:40 +0200, Wim Oudshoorn wrote:
> tbrownaw> > > Finally, I don't think I like the syntax you propose.  
> tbrownaw> > > Is this already used somewhare?
> tbrownaw> > > I think access control configuration is used in lots
> tbrownaw> > > of places, so maybe there is already a thought out
> tbrownaw> > > format for these kind of things.  
> tbrownaw> > > But he, I am not an expert on this at all.
> tbrownaw> >
> tbrownaw> > I don't think its great either, but I'm not sure what would be better.
> tbrownaw>
> tbrownaw> Random idea:
> tbrownaw>
> tbrownaw>
> tbrownaw> pattern "net.example.project.{security,private}*"
> tbrownaw> allow "[hidden email]"
> tbrownaw> allow "[hidden email]"
> tbrownaw>
> tbrownaw> pattern "net.example.{public,project}*"
> tbrownaw> others "allow"
>
> Random response:
>
> I think it's quite confusing how the format is sometimes
> 'verb "subject"' and sometimes 'subject "verb"'.  I would rather have
> some kind of consistency:
>
>  pattern "net.example.project.{security,private}*"
>  allow "[hidden email]"
>  allow "[hidden email]"
>  
>  pattern "net.example.{public,project}*"
>  allow "*"

But there needs to be some form of 'others "continue"'. Maybe 'continue
"true"', or just 'continue' without arguments?

Tim




_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: new default get_netsync_*_permitted hooks

Timothy  Brownawell
In reply to this post by Richard Levitte - VMS Whacker
On Mon, 2005-10-24 at 01:16 +0200, Richard Levitte - VMS Whacker wrote:

> tbrownaw> pattern "net.example.project.{security,private}*"
> tbrownaw> allow "[hidden email]"
> tbrownaw> allow "[hidden email]"
> tbrownaw>
> tbrownaw> pattern "net.example.{public,project}*"
> tbrownaw> others "allow"
>
> Random response:
>
> I think it's quite confusing how the format is sometimes
> 'verb "subject"' and sometimes 'subject "verb"'.  I would rather have
> some kind of consistency:
>
>  pattern "net.example.project.{security,private}*"
>  allow "[hidden email]"
>  allow "[hidden email]"
>  
>  pattern "net.example.{public,project}*"
>  allow "*"

It now uses this syntax. Keywords are "pattern", "allow", "deny", and
"continue". Every "pattern" line starts a new section, and it will only
"fall through" a block if it has a 'continue "true"' line. "deny" is the
default, so it's only useful in blocks with 'continue "true"' such as


# jim fubared this branch once already...
pattern "net.example.project.foobar*"
allow "[hidden email]"
deny "[hidden email]"
continue "true"

pattern "net.example.project*"
allow "[hidden email]"
allow "[hidden email]"
allow "[hidden email]"
allow "[hidden email]"
[...]


Any line that doesn't match ' *[^ ]* *".*"', or that doesn't have
"allow", "deny", "pattern", or "continue" as the first word is ignored.

Still TODO: the parser just looks for a word followed by a quoted
string. It should probably be improved to handle full basic_io, meaning
escaped chars in the string and any number (0+) of quoted strings using
either "" or [] . It should also be made to recognize comments properly,
possibly including comments at the end of lines with useful info.
   allow "joe" # comment about joe

write-permissions is still a simple list of keys, but now with "*"
instead of "--all--".

Tim




_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: new default get_netsync_*_permitted hooks

Nathaniel Smith
On Tue, Oct 25, 2005 at 10:10:58PM -0500, Timothy Brownawell wrote:
> Still TODO: the parser just looks for a word followed by a quoted
> string. It should probably be improved to handle full basic_io, meaning
> escaped chars in the string and any number (0+) of quoted strings using
> either "" or [] . It should also be made to recognize comments properly,
> possibly including comments at the end of lines with useful info.

[] in basic_io is not a generic string; it's 40 characters of hex,
exactly.

-- Nathaniel

--
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender


_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: new default get_netsync_*_permitted hooks

Bruce Stephens-2
In reply to this post by Timothy Brownawell
Timothy  Brownawell <[hidden email]> writes:

[...]

> Any line that doesn't match ' *[^ ]* *".*"', or that doesn't have
> "allow", "deny", "pattern", or "continue" as the first word is ignored.

That seems to allow a bit too much opportunity for undetected errors,
IMHO.  I think if I were writing it, I'd pin the syntax down more,
otherwise you may get things like:

# jim fubared this branch once already...
pattern "net.example.project.foobar*"
allow "[hidden email]"
deby "[hidden email]"
continue "true"

with unexpected effects.

[...]



_______________________________________________
Monotone-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/monotone-devel