Bug 784621

Summary:	[ipa webui] Reset password link is enabled for a user without permission to change it
Product:	Red Hat Enterprise Linux 6	Reporter:	Namita Soman <nsoman>
Component:	ipa	Assignee:	Rob Crittenden <rcritten>
Status:	CLOSED ERRATA	QA Contact:	Namita Soman <nsoman>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	6.2	CC:	jgalipea, mkosek, mvarun, pvoborni, xdong
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ipa-3.0.0-1.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 09:09:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Namita Soman 2012-01-25 15:23:39 UTC

Description of problem:
A user (possibly an admin with limited access) who has permission to update attributes for another user except password, logs in, the Reset Password link is enabled, indicating this user can reset it. It correctly will throw an error if an attempt is made. The other attributes that cannot be edited are all displayed as read only. To keep that look through the page, this link should not be clickable.

Version-Release number of selected component (if applicable):
ipa-server-2.2.0-101.20120123T0157zgit64cf8a4.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Add a permission
ipa permission-add AAA --filter='(givenname=xyz)' --permissions=write --attr=carlicense
2. Add a privilege with this permission, add a role with this privilege, add a user with this role
3. add a user with givenname=xyz
3.Kinit as the user with the role, edit user xyz 
  
Actual results:
carlicense can be updated (as expected) but can also click on link to reset password. Error will be thrown if an attempt is made.

Expected results:
The link to Reset password should not be enabled for this user.

Additional info:

Comment 1 Namita Soman 2012-01-25 15:29:28 UTC

Same behaviour in Hosts tab. If user has no permission, links to delete key, unprovision, set otp, and new cert are enabled

Comment 3 Martin Kosek 2012-01-27 09:22:05 UTC

I don't think it is that easy to check if the logged user has a privilege to reset somebody else's password. WebUI would have to evaluate all configured ACIs in the same way as dirsrv does.

CLI does it in the same way - anyone can call command to reset the password, but if the dirsrv rejects the change an appropriate error message is thrown:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: fbar.BOS.REDHAT.COM

Valid starting     Expires            Service principal
01/27/12 04:15:53  01/28/12 04:15:53  krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM
[root@vm-068 ~]# ipa passwd fbar2
New Password: 
Enter New Password again to verify: 
ipa: ERROR: Insufficient access: Insufficient access rights


If the error message given in the WebUI is clear and understandable I'd propose to close this ticket as WONTFIX.

Comment 4 Rob Crittenden 2012-01-27 14:24:11 UTC

The WebUI uses the output of --rights to determine what should be enabled. It may be that we aren't returning rights for userPassword or the UI does not have the Reset Password link tied into that, but it should be possible to know this in advance.

Comment 5 Martin Kosek 2012-01-30 07:59:56 UTC

Ah, you are right. I will create an upstream ticket so that it can be investigated.

Comment 6 Martin Kosek 2012-01-30 08:00:37 UTC

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2318

Comment 7 Petr Vobornik 2012-06-04 09:14:11 UTC

Fixed upstream bf9234dbd1911a6e720470844ad053053144cc45 .

Note: 'resete password' link was moved to action panel which is on the right in the same section of the page as original link.

Comment 8 Jenny Severance 2012-09-25 16:01:08 UTC

regression test is automated

Comment 12 Xiyang Dong 2012-11-28 16:06:57 UTC

Verifying

Comment 13 Xiyang Dong 2012-11-28 16:30:27 UTC

ipa version:

ipa-server-3.0.0-8.el6.x86_64

how to verify:
1. Add a permission which has filter='(givenname=xyz)',permissions=write, attr=carlicense
2. Add a privilege with this permission, add a role with this privilege,create a user abc with this role
3. create  user xyz with givenname=xyz
4.login as user abc
5.verify that the password reset is disabled for user xyz.
6.login as admin
7.remove user abc xyz
8.remove permission,privilege,role

Comment 14 Namita Soman 2012-11-28 16:32:26 UTC

xdong verified using steps above

Comment 16 errata-xmlrpc 2013-02-21 09:09:35 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0528.html