permissions on refs/meta/config and User/Project Owners group

[Peter Niederlag]

Hi,

adding an explicit push permission on 'refs/meta/config' results in:

Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Branch refs/meta/config:
remote: You are not allowed to perform this operation.
remote: Configuration changes can only be pushed by project owners
remote: who also have 'Push' rights on refs/meta/config

However adding a push permission on 'refs/meta/*' works fine.

Is this somehow related to:
http://code.google.com/p/gerrit/source/detail?r=843032f2f9287e1df75bee1b72fce6b498eba4a7
?

gerrit 2.5-rc0, user is in Adminstrators group.

Also we are still struggling to fully understand the Owner Category and
it's interaction with the Project Owners group.

For our understanding the Owner category assigns the groups that will be
considered when assigning a right on the "Project Owners" group.

The Owner category can be set on any "ref pattern". According to the
docu the Owner category has mostly implications on the Web-Gui. To us it
seems like the "ref pattern" is not applicable here. For example
changing the project description is either possible or not but can't be
tied to a "ref pattern".

Also the "Project Owners" group will be assigned on specific "ref
patterns". How does this interact with the "ref pattern" of the owner
category.

Does anybody have some more help/examples on the Owner category and it's
implications?

Thx and Greets,
Peter

[Edwin Kempin]

2012/10/16 Peter Niederlag <peter.n...@googlemail.com>

Hi,

adding an explicit push permission on 'refs/meta/config' results in:

Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Branch refs/meta/config:
remote: You are not allowed to perform this operation.
remote: Configuration changes can only be pushed by project owners
remote: who also have 'Push' rights on refs/meta/config

However adding a push permission on 'refs/meta/*' works fine.

Is this somehow related to:
http://code.google.com/p/gerrit/source/detail?r=843032f2f9287e1df75bee1b72fce6b498eba4a7
?

Yes, this is related. As you can see from the commit message the idea was to disallow assigning
the push access for refs/meta/config on the All-Project project, because this effectivly makes the user a Gerrit admin.
The current situation is a bit of a mess:
1. You can still assign the push access right on the All-Projects project for 'refs/meta/*' or 'refs/*',
    which makes the user have it for 'refs/meta/config' as well
2. Even as Gerrit admin you need to have the push access right for refs/meta/config, which is bad if you can't assign it...
    currently it's possible due to 1.
There is definitely a need to fix this.

gerrit 2.5-rc0, user is in Adminstrators group.

Also we are still struggling to fully understand the Owner Category and
it's interaction with the Project Owners group.

The 'Project Owners' group can be understood as a role. You can use it to
assign access rights to those groups which are owning the project, without
knowing yet, which groups these will be.

For our understanding the Owner category assigns the groups that will be 

considered when assigning a right on the "Project Owners" group.

The 'Project Owners' group is then resolved within the context of a concrete
project to those groups which have the 'Owner' access right on 'ref/*'.
Having the Owner access right on 'refs/*' allows you to administrate the
project and hence you are project owner.

The Owner category can be set on any "ref pattern". According to the
docu the Owner category has mostly implications on the Web-Gui. To us it
seems like the "ref pattern" is not applicable here. For example
changing the project description is either possible or not but can't be
tied to a "ref pattern".

Owner access rights assigned for efs other than 'refs/*' just makes you owner
for this ref or ref namespace, but not project owner. Hence these other
Owner access rights don't play a role when resolving the 'Project Owners' group.
 

Also the "Project Owners" group will be assigned on specific "ref
patterns". How does this interact with the "ref pattern" of the owner
category.

Let's just take a simple example:
GroupA                Owner            refs/*
GroupB                Owner            refs/*
GroupC                Owner            refs/release/*
Project Owners     Forge-Author  refs/release/*

This would resolve to:
GroupA                Owner            refs/*
GroupB                Owner            refs/*
GroupC                Owner            refs/release/*
GroupA                Forge-Author  refs/release/*
GroupB                Forge-Author  refs/release/*


 

Does anybody have some more help/examples on the Owner category and it's
implications?

Thx and Greets,
Peter

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

[Peter Niederlag]

Hi,

big thx for your explanations. Now it makes more sense but still I have
some questions:

On 16.10.2012 13:55, Edwin Kempin wrote:
> 2012/10/16 Peter Niederlag <peter.n...@googlemail.com>
[...]

> Yes, this is related. As you can see from the commit message the idea was
> to disallow assigning
> the push access for refs/meta/config on the All-Project project, because
> this effectivly makes the user a Gerrit admin.

Well, if I am Owner or Member of the "All-Project" project and have push
permissions this seems to be fine for me. Why is this so bad?

This only gets bad if I assign some push right on refs/meta/config for
"anonymous" or "registered" groups. as long as I have control over the
group and its members that I assign push to "refs/meta/config" this
really seems fine to me. Probably overlooking something?

"All-Project" refs/meta/config push/write/update seems to be kind of
pretty much Gerrit admin terrain anyway, isn't it?

> The current situation is a bit of a mess:
> 1. You can still assign the push access right on the All-Projects project
> for 'refs/meta/*' or 'refs/*',
> which makes the user have it for 'refs/meta/config' as well
> 2. Even as Gerrit admin you need to have the push access right for
> refs/meta/config, which is bad if you can't assign it...
> currently it's possible due to 1.
> There is definitely a need to fix this.

Actually I don't even care that much for the config of the "All Project"
itself. Due to some refactoring of group and project names we just need
to be able to batch update all refs/meta/config via a script/batch role
and ran into this issue.

So actually we are looking into a proper way to grant access on
refs/meta/config of "any" project for admins. Giving project owners
access to refs/meta/config could be nice but acually probably not really
required.

[...]


Thx and Greets,
Peter

[Edwin Kempin]

2012/10/16 Peter Niederlag <peter.n...@googlemail.com>

Hi,

big thx for your explanations. Now it makes more sense but still I have
some questions:

On 16.10.2012 13:55, Edwin Kempin wrote:
> 2012/10/16 Peter Niederlag <peter.n...@googlemail.com>
[...]

> Yes, this is related. As you can see from the commit message the idea was
> to disallow assigning
> the push access for refs/meta/config on the All-Project project, because
> this effectivly makes the user a Gerrit admin.

Well, if I am Owner or Member of the "All-Project" project and have push
permissions this seems to be fine for me. Why is this so bad?

The argument is like this:
- If you can push to the refs/meta/config branch of the All-Projects
  you can change the global compabilities
- Being able to change the global capabilities means you can assign
  the 'Administrate Server' capability (also to yourself)
- It is not obvious that granting push for refs/meta/config on the All-Projects
  project effectivly means to assign these users Gerrit administrator permissions
- to avoid this confusion the idea was to disallow granting this access right and
  allow only real Gerrit administrators (those that have the global capability
  'Administrate Server' assigned) to push to refs/meta/config in the All-Projects
  project
 

This only gets bad if I assign some push right on refs/meta/config for
"anonymous" or "registered" groups. as long as I have control over the
group and its members that I assign push to "refs/meta/config" this
really seems fine to me. Probably overlooking something?

"All-Project" refs/meta/config push/write/update seems to be kind of
pretty much Gerrit admin terrain anyway, isn't it?

Yes, only Gerrit Administrators should be allowed to do this.
 

[Steffen Gebert]

Thanks, Edwin.

> - to avoid this confusion the idea was to disallow granting this access right and
> allow only real Gerrit administrators (those that have the global capability
> 'Administrate Server' assigned) to push to refs/meta/config in the All-Projects
> project

> ..

> > "All-Project" refs/meta/config push/write/update seems to be kind of
> > pretty much Gerrit admin terrain anyway, isn't it?
> Yes, only Gerrit Administrators should be allowed to do this.

But being just member of Administrators didn't work out for us (that's why we tried to figure out, which permissions are really required).

Steffen (working together with Peter :))

[Edwin Kempin]

2012/10/16 Steffen Gebert <ste...@steffen-gebert.de>

Thanks, Edwin.

> - to avoid this confusion the idea was to disallow granting this access right and
>  allow only real Gerrit administrators (those that have the global capability
>  'Administrate Server' assigned) to push to refs/meta/config in the All-Projects
>  project

> ..

> > "All-Project" refs/meta/config push/write/update seems to be kind of
> > pretty much Gerrit admin terrain anyway, isn't it?
> Yes, only Gerrit Administrators should be allowed to do this.

But being just member of Administrators didn't work out for us (that's why we tried to figure out, which permissions are really required).

Yes, you should be Admin + having push access rights on refs/meta/config.
It's the same with pushing to any other ref, just being admin doesn't allow you to push, but even as admin you need the push access right.