https://bugzilla.redhat.com/show_bug.cgi?id=711667
When doing a modification using sudorule-mod, the whole string of comma separated users are accepted as a single value.
# ipa sudorule-add shanks-rule1 # ipa sudorule-add-runasuser shanks-rule1 --users=test1,test2,test3,test4 # ipa sudorule-find shanks-rule1 --all --raw dn: ipauniqueid=f7a20452-918c-11e0-9551-525400deab7b,cn=sudorules,cn=sudo,dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com cn: shanks-rule1 ipaenabledflag: TRUE ipasudorunasextuser: test1 ipasudorunasextuser: test3 ipasudorunasextuser: test2 ipasudorunasextuser: test4 ipauniqueid: f7a20452-918c-11e0-9551-525400deab7b objectclass: ipaassociation objectclass: ipasudorule ---------------------------- Number of entries returned 1 ---------------------------- # ipa sudorule-mod shanks-rule1 --runasexternaluser=user1,user2,user3,user4 # ipa sudorule-find shanks-rule1 --all --raw dn: ipauniqueid=f7a20452-918c-11e0-9551-525400deab7b,cn=sudorules,cn=sudo,dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com cn: shanks-rule1 ipaenabledflag: TRUE ipasudorunasextuser: user1,user2,user3,user4 <------------- ipauniqueid: f7a20452-918c-11e0-9551-525400deab7b objectclass: ipaassociation objectclass: ipasudorule ---------------------------- Number of entries returned 1 ----------------------------
Unable to mod multiple users using sudorule-mod.
Similar bug https://bugzilla.redhat.com/show_bug.cgi?id=711671
Might be another parameter parsing issue John is working on. Assigning to John for now.
fixed in [PATCH 29/29] Remove sudorule_mod, ticket 1307
sudorule_mod was ill-conceived, it does not respect the logic surrounding external users. Suggested to use sudorule_add and sudorule_del for modification.
Can you please explain better why you can no longer modify a rule? All other CLIs allow modification. Is this well defined and updated in the man pages? I'm not sure this was the right decision? I need some convincing ;-)
The decision was essentially Rob's. The fundamental problem is that we have this odd distinction of internal and external users/groups. The ldap modification logic is unaware of this distinction. Combined with the fact the internal code logic is unaware of comma separated lists for specific attributes (but the add command is). Therefore I believe Rob concluded it's more sensible to use add/delete rather than open a can of worms. Maybe Rob would to add his 2 cents here.
We can't drop the mod command completely because of API backwards compatibility. I also investigated adding no_create and no_update to the flags for these options and that won't work either for the same reason.
There is no logic behind these options, they update the attributes directly as seen in the original report. We shouldn't have allowed them in the first place but since we have an add-only rule I think we'll need to simply deprecate their usage. If you pass in values for these you'll get an error message back telling you how to properly set them.
attachment freeipa-rcrit-842-sudorule.patch
master: d8c4797
Metadata Update from @rcritten: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.1 - 2011/07
Login to comment on this ticket.