[one-users] Assigning limited admin rights

Mon Apr 14 06:49:58 PDT 2014

Hi,

Good idea, but with the admin group as secondary group the admin user gets
the 'user' view in Sunstone, not the 'admin' view. It seems that views
defined for secondary groups do not appear in Sunstone's settings. After
defining the 'admin' view for that particular user, I can select it, but I
find this complicated. This way, adding an admin requires me to edit
sunstone-views.yaml (that's not really the problem) and restarting Sunstone
(which kicks all users out of their sessions). It's not really a big deal
(I don't add admins on a daily basis), but I would have expected that
Sunstone offers me all views that are defined for all groups that I am
(primary or secondary) member of.

Greetings
Wilma

2014-04-10 16:48 GMT+02:00 Carlos Martín Sánchez <cmartin at opennebula.org>:

> Hi,
>
> On Wed, Apr 9, 2014 at 5:27 PM, Wilma Hermann <wilma.hermann at gmail.com>wrote:
>
>> Hi,
>>
>> To answer my own mail, I could resolve both problems. For the sake of
>> completeness, here's how:
>>
>>    1. I'm using a hook to change a new user's group after creation using
>>    the approach from this thread:
>>    http://lists.opennebula.org/pipermail/users-opennebula.org/2013-September/024648.html
>>
>>
> You could also put your admin user in the users group as the primary
> group, and add the admin group as a secondary group. This way it all new
> users will belong to the 'users' group.
>
> Regards
>
> --
> Carlos Martín, MSc
> Project Engineer
> OpenNebula - Flexible Enterprise Cloud Made Simple
> www.OpenNebula.org <http://www.opennebula.org/> | cmartin at opennebula.org
>  | @OpenNebula <http://twitter.com/opennebula> <cmartin at opennebula.org>
>
>
>
>>
>>    1.
>>    2. The problem here was that I used the vdcadmin view in Sunstone for
>>    the user. By debugging I found out that the list of groups in Sunstone is
>>    populated by some javascript loaded by the groups panel. In the vdcadmin
>>    view, the groups panel is disabled by default, therefore the list of groups
>>    is empty. It's arguably either a bug or a strict permission management
>>    thing, I can't justice on that. However, if I enable the groups panel and
>>    prevent the user from doing changes to the groups, I have everything I
>>    wanted to build.
>>
>> Greetings
>> Wilma
>>
>>
>> 2014-04-07 13:35 GMT+02:00 Wilma Hermann <wilma.hermann at gmail.com>:
>>
>> Hi,
>>>
>>> Thanks for the info, it was very useful. I'm still having two issues:
>>>
>>>
>>>    1. The default group of a new user is the same as the creating
>>>    user's one. I would like to have new users in the "users" group by default.
>>>    Is there a way to change this behavior?
>>>    2. In Sunstone, the user doing the user management does not see the
>>>    existing groups even though he ought to. I created an ACL "#<user_id>
>>>    GROUP/* USE+MANAGE+ADMIN", but still the list of groups I can assign to a
>>>    user through Sunstone is empty (Even the string "Please select" does not
>>>    appear). On the command line, a "oneuser chgrp" works flawlessly using this
>>>    account, so I guess it's a bug in Sunstone.
>>>
>>> Greetings
>>> Wilma
>>> 2014-04-04 10:34 GMT+02:00 Carlos Martín Sánchez <cmartin at opennebula.org
>>> >:
>>>
>>> > Hi,
>>> >
>>> > Adding to what Rubén said, the acl modification is only allowed for
>>> users in
>>> > the oneadmin group.
>>> >
>>> > Make sure you use the reference command-auth tables in the xml-rpc doc
>>> [1]
>>> > to create your rules.
>>> >
>>> > For example, oneuser passwd requires USER:MANAGE. The rule "#<user_id>
>>> > USER/* USE+MANAGE+ADMIN" will allow your user to change oneadmin's
>>> password.
>>> > In this case, you will want to create a rule targeting each group
>>> (excluding
>>> > oneadmin).
>>> >
>>> > Regards
>>> >
>>> > [1]
>>> >
>>> http://docs.opennebula.org/4.4/integration/system_interfaces/api.html#authorization-requests-reference
>>> > --
>>> > Carlos Martín, MSc
>>> > Project Engineer
>>> > OpenNebula - Flexible Enterprise Cloud Made Simple
>>> > www.OpenNebula.org | cmartin at opennebula.org | @OpenNebula
>>> >
>>> >
>>> > On Thu, Apr 3, 2014 at 2:19 PM, Ruben S. Montero <
>>> rsmontero at opennebula.org>
>>> > wrote:
>>> >>
>>> >> Hi
>>> >>
>>> >> Probably, the following may work...
>>> >>
>>> >> oneacl create "#<user_id> USER/* CREATE"
>>> >> oneacl create "#<user_id> USER/* USE+MANAGE+ADMIN"
>>> >>
>>> >> Take a look to the ACL guide for more info:
>>> >>
>>> >>
>>> >>
>>> http://docs.opennebula.org/4.4/administration/users_and_groups/manage_acl.html
>>> >>
>>> >> Cheers
>>> >>
>>> >> Ruben
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Apr 3, 2014 at 12:08 PM, Wilma Hermann <
>>> wilma.hermann at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> Is it possible to assign limited admin rights to certain accounts? I
>>> >>> would like to have a user that is allowed to do all the user
>>> >>> management (creating users, adding users to existing groups, etc.)
>>> >>> without adding this user to the oneadmin-group. In particular, I
>>> would
>>> >>> like to deny this user access to all other users' VMs, templates,
>>> >>> images, etc. The user also shouldn't have write-access to the ACLs
>>> >>> (otherwise limits would make no sense obviously).
>>> >>>
>>> >>> Greetings
>>> >>> Wilma
>>> >>> _______________________________________________
>>> >>> Users mailing list
>>> >>> Users at lists.opennebula.org
>>> >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> --
>>> >> Ruben S. Montero, PhD
>>> >> Project co-Lead and Chief Architect
>>> >> OpenNebula - Flexible Enterprise Cloud Made Simple
>>> >> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>>> >>
>>> >> _______________________________________________
>>> >> Users mailing list
>>> >> Users at lists.opennebula.org
>>> >> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>> >>
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20140414/caff8916/attachment-0002.htm>