[PATCH] acl: support negating the list of users/groups with leading "~"

[John Mulligan]

On Mon, Feb 07, 2011 at 09:57:55PM -0600, Matt Mackall wrote:
> On Mon, 2011-02-07 at 18:08 -0500, John Mulligan wrote:
> > On Mon, Feb 07, 2011 at 04:31:55PM -0600, Matt Mackall wrote:
> > > The ACL rules are -already- too complex.
> > > 
> > 
> > I can't disagree with that. After all, I tried a bunch of configs that I
> > thought might fix our issue before reaching for the code. Plus I hadn't
> > even looked at the file based part.
> > 
> > I can think of a couple of other approaches that get us what we want.
> >  1) Have a general option of default deny or default accept. If default
> >     accept is set the accept rules only apply to the excplicly listed
> >     branches.
> >  2) Have a special name/symbol that would apply to all branches that are
> >     not explictily listed.
> > 
> > I'm leaning more toward the first option, but I'd like to find out what
> > you might have in mind for improving the situation for all users.
> 
> (1) is problematic, because it turns the whole world upside-down on any
> rules you've already got and you can get into trouble if you for some
> reason want different behaviors in different places.
> 

That makes sense.

> So I think a catch-all might be a better plan.
> 

Sounds good. In order not to change any user's existing acl
configuration we probably can not change the current behavior
of the existing '*' catch all. Right now a configuration like the following:

  [acl.allow.branches]
  foobar = alice
  * = bob

Gives bob access to all the branches including foobar. We want all users
access all "unlisted" branches. But since '* = *' just ends up giving
all user access everywhere. So I think that a new symbol, possibly '.',
would do the trick. I don't think that conflicts with anything
exisiting. Then the following:

  [acl.allow.branches]
  foobar = alice
  . = *

Would allow alice and only alice access to foobar, and all users access
to the remaining branches. The only thing I'm not sure about with this
idea is how it might interact with the file based acls. We're only
interested in branch acls at this point, so I'm not sure if this
concept would be useful for file acls or we should make this part of
the branch based acl configuration only.

Opinions?