Hide Forgot
Description of problem: When modifying an existing permission to just modify its permissions, it prompts for all parameters to be entered again 1> Add a permission to have read and write permissions: # ipa permission-add ManageUser --permissions="read,write" --type=user --attr=carlicense,description ----------------------------- Added permission "ManageUser" ----------------------------- Permission name: ManageUser Permissions: read, write Attributes: carlicense, description Type: user 2> Modify the permission to have just read permission: # ipa permission-mod ManageUser --permissions=read [Attributes]: carlicense [Type]: user [Member of group]: [Filter]: [Subtree]: [Target group]: -------------------------------- Modified permission "ManageUser" -------------------------------- Permission name: ManageUser Permissions: read Attributes: carlicense Type: user Had to enter all parameters again. Version-Release number of selected component (if applicable): freeipa-server-2.1.4-4.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. Add a permission as above 2. Modify this permission - as above Actual results: have to re-enter all parameters, even those that are not changing. Expected results: Modify permission based on what is provided in the command, and not prompt for all attr. Additional info:
Upstream ticket: https://fedorahosted.org/freeipa/ticket/2280
When modifying a permission, I suspect, the target cannot be changed. So for example, if a permission was added with --subtree=cn=computers,cn=accounts,dc=testrelm, it cannot be edited to now be type=host If such changes are not valid, expecting a command switching target will throw an error. # ipa permission-add ManageHost --permissions=read --subtree=cn=computers,cn=accounts,dc=testrelm # ipa permission-add ManageHost --permissions=read --type=host should throw error- ipa: ERROR: invalid 'target': type, filter, subtree and targetgroup are mutually exclusive or some error indicating target cannot be switched. is that correct expectation? Or can target be changed?
subtree is just a more generic way of defining type. --type just predefines some existing containers that IPA creates.
Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/677ea8cbfab8aadbd89ca479ed4453776f65fd30
Verified using ipa-server-3.0.0-20.el6.x86_64 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipa-permission-cli-1060 - modify permission --rename (bug 805478 and Bug 782847) :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [10:26:03] :: Executing: ipa permission-mod APermission --rename=ABCPermission --------------------------------- Modified permission "APermission" --------------------------------- Permission name: ABCPermission Permissions: write Type: user :: [10:26:05] :: Modified permission APermission successfully :: [ PASS ] :: Running 'modifyPermission "APermission" rename ABCPermission' :: [10:26:05] :: Executing: ipa permission-show --all "ABCPermission" > /tmp/tmp.nqBo9qpHMv/permissionshow.out Permission name: ABCPermission :: [10:26:06] :: ipa permission ABCPermission Verification successful: Value of Permission name: = ABCPermission :: [ PASS ] :: Verify Permissions
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