Bug 1020091

Summary:	Group specific root password is only shared with group owners
Product:	[Retired] Beaker	Reporter:	Nick Coghlan <ncoghlan>
Component:	web UI	Assignee:	Amit Saha <asaha>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.14	CC:	aigao, asaha, dcallagh, ebaak, jingwang, llim, qwan, rmancy
Target Milestone:	0.15.2
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-19 07:03:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nick Coghlan 2013-10-17 02:04:48 UTC

Currently, the web UI only displays the group root password to group owners rather than to all group members. This means group members may be surprised when neither their personal root password (if configured) nor the current global default root password works for jobs submitted on behalf of the group.

The original design intent (from [1]) was for group owners to be able to use the Beaker UI to share the group password with group members, just as the Beaker UI is used to share the current default password with all users of the instance:

"The given root password will be used when provisioning jobs for this group. It will be visible on the group page to other members of the group. If the password is given in the clear Beaker will not automatically hash it before storing, to make it easier to share amongst the group (This behaviour deliberately differs from that for individual root passwords set on the Preferences page - when given in the clear, individual passwords are automatically hashed before storage)."

(Note that group owners may still choose to enter the group password in already hashed form, in which case it will need to be shared with group members through some external means)

The problem is made worse in 0.14 by the fact that bug 990860 means group members can't even easily identify the group owners to ask for the password (or if one is set).

[1] http://beaker-project.org/dev/proposals/enhanced-user-groups.html#root-password-configuration

Comment 1 Amit Saha 2013-12-04 20:27:50 UTC

http://gerrit.beaker-project.org/#/c/2583/1

Comment 3 wangjing 2013-12-09 11:47:10 UTC

tested on beaker-devel(beaker-server-0.15.2-0.git.100.813f501.el6eng.noarch.rpm)-->partly fail

1. group owner can change the group password-->pass
2. admin(not in the group) can change the group password?-->fail, admin(not in the group) can change the password, but cannot see it?

3. admin(in the group) can change the group password?-->pass

4. group members(non-admin) cant update group password.-->pass
5. checking activity of changing group password-->fail, no activity.

6. group members could see the group password on group page.-->pass

Additional questions:
1. where to get the latest bkr cli, for testing 'bkr group-modify --root-password=<thevalue>'
2. seems all the jobs submitted on yesterday afternoon are marked status 'waiting', so blocked thus tests:
(1)group members use group password login system provisioned for group jobs.
(2)group members use their public SSH keys login system provisioned for group jobs.
(3)when 'No group root password set', Group jobs will use the root password preferences of the submitting user.

Comment 5 Amit Saha 2013-12-10 00:36:18 UTC

(In reply to wangjing from comment #3)
> tested on
> beaker-devel(beaker-server-0.15.2-0.git.100.813f501.el6eng.noarch.rpm)--
> >partly fail
> 
> 1. group owner can change the group password-->pass
> 2. admin(not in the group) can change the group password?-->fail, admin(not
> in the group) can change the password, but cannot see it?

Yes, admin cannot see it because admin is not a group member. 'admin' is a special user with special priviliges, and admin won't login and submit a job. However, if we want to do so, we can. I am not entirely sure if that is useful other than the sake of consistency.




> 
> 3. admin(in the group) can change the group password?-->pass
> 
> 4. group members(non-admin) cant update group password.-->pass
> 5. checking activity of changing group password-->fail, no activity.
> 
> 6. group members could see the group password on group page.-->pass
> 
> Additional questions:
> 1. where to get the latest bkr cli, for testing 'bkr group-modify
> --root-password=<thevalue>'
> 2. seems all the jobs submitted on yesterday afternoon are marked status
> 'waiting', so blocked thus tests:
> (1)group members use group password login system provisioned for group jobs.
> (2)group members use their public SSH keys login system provisioned for
> group jobs.
> (3)when 'No group root password set', Group jobs will use the root password
> preferences of the submitting user.

Comment 6 Nick Coghlan 2013-12-10 05:51:41 UTC

While admins can *technically* alter a group specific password, it's really designed to be managed by the group owners. If the admin really wants to see it, they can just add themselves to the group first.

Admins should be able to change the group password from the command line, though.

Comment 8 wangjing 2013-12-10 08:12:44 UTC

verified on beaker-devel(beaker-server-0.15.2-0.git.100.813f501.el6eng.noarch.rpm)-->partly fail

1. group owner can change the group password-->pass
2. admin(not in the group) can change the group password-->pass
3. admin(in the group) can change the group password-->pass
4. group members(non-admin) cant update group password.-->pass

5. checking activity of changing group password both on webUI and via CLI-->fail, no activity when changing on webUI.
 
6. group members could see the group password on group page.-->pass
7. admin(in/not in group) can change group password via CLI: 'bkr group-modify --root-password=<thevalue>'-->pass
8. normal user(group owner)can change group password via CLI-->pass
9. normal user(non-groupowner) cant change group password via CLI-->pass
10. group members use group password login system provisioned for group jobs.-->pass
11. group members use their public SSH keys login system provisioned for group jobs.-->pass
12. when 'No group root password set', Group jobs will use the root password
 preferences of the submitting user.-->pass

Comment 9 Amit Saha 2013-12-10 23:22:32 UTC

(In reply to wangjing from comment #8)
> verified on
> beaker-devel(beaker-server-0.15.2-0.git.100.813f501.el6eng.noarch.rpm)--
> >partly fail
> 

> 5. checking activity of changing group password both on webUI and via
> CLI-->fail, no activity when changing on webUI.

Could you please file this as a separate bug? Its unrelated to this bug as far as I can understand.

Comment 10 Nick Coghlan 2013-12-11 05:59:12 UTC

+1 for splitting out the lack of activity tracking as a new bug - that looks like an existing defect in updating the group password through the web UI, rather than a new problem introduced by this patch.

Comment 11 wangjing 2013-12-11 06:26:04 UTC

(In reply to Amit Saha from comment #9)
> (In reply to wangjing from comment #8)
> > verified on
> > beaker-devel(beaker-server-0.15.2-0.git.100.813f501.el6eng.noarch.rpm)--
> > >partly fail
> > 
> 
> > 5. checking activity of changing group password both on webUI and via
> > CLI-->fail, no activity when changing on webUI.
> 
> Could you please file this as a separate bug? Its unrelated to this bug as
> far as I can understand.

so, could u tell more detail about the reason? at least the defect u mentioned affects one of the features in this bug(activity of changing group password both on webUI), I suggest to file another bug which blocks this bug.

Comment 12 Amit Saha 2013-12-11 06:30:41 UTC

(In reply to wangjing from comment #11)
> (In reply to Amit Saha from comment #9)
> > (In reply to wangjing from comment #8)
> > > verified on
> > > beaker-devel(beaker-server-0.15.2-0.git.100.813f501.el6eng.noarch.rpm)--
> > > >partly fail
> > > 
> > 
> > > 5. checking activity of changing group password both on webUI and via
> > > CLI-->fail, no activity when changing on webUI.
> > 
> > Could you please file this as a separate bug? Its unrelated to this bug as
> > far as I can understand.
> 
> so, could u tell more detail about the reason? at least the defect u
> mentioned affects one of the features in this bug(activity of changing group
> password both on webUI), I suggest to file another bug which blocks this bug.

This bug is about "showing" the password to all group members. It doesn't relate to changing the password and it being shown in the list of activities. 

A new bug should be filed, but it shouldn't be a blocker for this bug. They are not related.

Comment 13 wangjing 2013-12-11 06:43:56 UTC

(In reply to Amit Saha from comment #12)
> (In reply to wangjing from comment #11)
> > (In reply to Amit Saha from comment #9)
> > > (In reply to wangjing from comment #8)
> This bug is about "showing" the password to all group members. It doesn't
> relate to changing the password and it being shown in the list of
> activities. 
> 
> A new bug should be filed, but it shouldn't be a blocker for this bug. They
> are not related.

suppose the feature arranged in docs(links in comment0) are all included in this bug:
'Changes to the group’s root password are recorded in the “Group Activity” log. The activity log only records when the change occurred, and the user that made the change - the password itself is not recorded in the activity log, not even in hashed form).'

well, filed a new bug 1040299 for recording.

Comment 14 wangjing 2013-12-11 06:45:48 UTC

based on comment9/10/11/12/13, verify this bug.

Comment 15 Amit Saha 2013-12-19 07:03:58 UTC

Release announcement: https://lists.fedorahosted.org/pipermail/beaker-devel/2013-December/000923.html