Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Add a permission to allow a user to update a dns record's aRecord. Add a user to have this permission, and log in as this user.
To update the dnsrecord's aRecord, click on it to open it.
And you see:
Error: IPA Error 3007
'idnsname' is required
Using cli, can update record successfully.
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 ABC --permissions=write --subtree=idnsname=testrelm.com,cn=dns,dc=testrelm,dc=com --attr=nSRecord,aRecord,idnsZoneActive
2. Add a privilege, a role, a user, and assign the role to this user
3. kinit as this user
4. Go to DNSZones - testrelm.com - ipaqavmf (or similar path depending on test env)
Actual results:
Error: IPA Error 3007
'idnsname' is required
Expected results:
To be able to open this record, and update its aRecord
Additional info:
Using CLI can do the above.
1> dnsrecord for ipaqavmf is as below:
# ipa dnsrecord-show --all --raw
Zone name: testrelm.com
Record name: ipaqavmf
dn: idnsname=ipaqavmf,idnsname=testrelm.com,cn=dns,dc=testrelm,dc=com
idnsname: ipaqavmf
arecord: 10.16.98.191
objectclass: top
objectclass: idnsrecord
2> update its aRecord (this user has permission to do so):
# ipa dnsrecord-mod --setattr="aRecord=10.16.98.192"
Zone name: testrelm.com
Record name: ipaqavmf
Record name: ipaqavmf
A record: 10.16.98.192
3> update its idnsname (this user does not have permission to do so):
# ipa dnsrecord-mod --setattr="idnsname=ipaqb"
Zone name: testrelm.com
Record name: ipaqavmf
ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'idnsName' attribute of entry 'idnsname=ipaqavmf,idnsname=testrelm.com,cn=dns,dc=testrelm,dc=com'.
Works for me (ipa-2-2).
But error
{{{
Error: IPA Error 3007
'idnsname' is required
}}}
Is a general UI error which sometimes occur. It most likely doesn't have any connection with permissions. It's exact cause is not yet determined and I didn't encounter it for quite a while (maybe it got self-fixed).
Do you have exact steps how to reproduce it? 'Go to DNSZones - testrelm.com - ipaqavmf (or similar path depending on test
env)' is vague. Is it by direct link or, clicking throw UI? Was it automated or manual? (timings).
I'll just add that Error 3007 means that we didn't send a required parameter for command. The question is "Why? resp. "When?".
If it is really always reproducible I would like to know more details of step #4 (as said in previous comment).
The behaviour changed with the fix available for bug 807361. The new permission also has to be provided in spite of the one used in example above to list zones. But either way - the error is not displayed.