Bug 1140888 - Broken dereference control with the FreeIPA 4.0 ACIs
Summary: Broken dereference control with the FreeIPA 4.0 ACIs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 1112824 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-12 00:52 UTC by Noriko Hosoi
Modified: 2015-03-05 09:36 UTC (History)
13 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1112702
Environment:
Last Closed: 2015-03-05 09:36:48 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Comment 2 Noriko Hosoi 2014-10-16 23:44:59 UTC
*** Bug 1112824 has been marked as a duplicate of this bug. ***

Comment 3 Sankar Ramalingam 2014-11-21 14:20:35 UTC
Checking whether this can be verified by IPA team?

Comment 4 Scott Poore 2014-11-24 22:21:48 UTC
I'm looking at this for IPA.  I need some info on how this is done for RHEL7.

To reproduce, do I need to test with a RHEL7 Master and Replica?

I tried with a RHEL6.6 Master and RHEL7 Replica and I hit the same issues from bug #1139361 with ssh as admin:

master:
[root@vm-idm-057 ~]# rpm -q ipa-server 389-ds-base
ipa-server-3.0.0-42.el6.x86_64
389-ds-base-1.2.11.15-48.el6_6.x86_64

replica:
[root@vm-idm-041 log]# rpm -q ipa-server 389-ds-base
ipa-server-4.1.0-7.el7.x86_64
389-ds-base-1.3.3.1-9.el7.x86_64

########################################################
#

[root@vm-idm-057 ~]# ssh admin@$(hostname)
Connection closed by UNKNOWN

And I don't see anything doing the ldapsearch from the previous verification:

[root@vm-idm-057 ~]# ldapsearch -Y GSSAPI -b "fqdn=vm-idm-057.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test" -E 'deref=managedBy:objectclass'
SASL/GSSAPI authentication started
SASL username: admin@TESTRELM.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=vm-idm-057.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#

# search result
search: 4
result: 0 Success

# numResponses: 1

Comment 5 Rich Megginson 2014-11-24 22:33:06 UTC
Adding Ludwig since Noriko is on pto.

Comment 7 Scott Poore 2014-11-25 14:59:36 UTC
I'm seeing a lot of errors like these in the dirsrv logs:

[25/Nov/2014:02:21:20 +051800] NSACLPlugin - Error: This  ((targetattr = "a6record || aaaarecord || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord")(target = "ldap:///idnsname=*,cn=dns,dc=testrelm,dc=test")(version 3.0;acl "permission:System: Update DNS Entries";allow (write) groupdn = "ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=testrelm,dc=test";)) ACL will not be considered for evaluation because of syntax errors.

[25/Nov/2014:02:21:20 +051800] NSACLPlugin - __aclp__init_targetattr: targetattr "ipaanchoruuid" does not exist in schema. Please add attributeTypes "ipaanchoruuid" to schema if necessary. 

[25/Nov/2014:02:21:20 +051800] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr = "ipaanchoruuid

[25/Nov/2014:02:21:20 +051800] NSACLPlugin - Error: This  ((targetattr = "ipaanchoruuid")(target = "ldap:///cn=*,cn=compat,dc=testrelm,dc=test")(targetfilter = "(objectclass=ipaOverrideTarget)")(version 3.0;acl "permission:System: Compat Tree ID View targets";allow (compare,read,search) userdn = "ldap:///anyone";)) ACL will not be considered for evaluation because of syntax errors.

Is this a problem?

Comment 8 Ludwig 2014-11-25 15:09:50 UTC
don't know where you did take the acis from, but you need also have the proper schema, otherwise the acis or parts of  the acis will not be loaded, and you don't know what you're testing.

Why don't you use the steps provided to test with DS alone ?

Comment 9 Ludwig 2014-11-25 15:12:07 UTC
teh steps are copied from: https://bugzilla.redhat.com/show_bug.cgi?id=1112702#c25

Comment 10 Scott Poore 2014-11-25 15:40:02 UTC
Ludwig, 

I was testing from the IPA perspective of mixed environment.  I believe we're also looking at the DS alone test you listed.  

However, don't the findings there indicate a problem with installing a RHEL7.1 IPA replica with a RHEL6.6 IPA server if the schema's not being setup correctly?

Do I need to file that as a separate bug against IPA?

Thanks,
Scott

Comment 11 Ludwig 2014-11-25 15:43:09 UTC
as I said, I don't know what you did. If you have two different versions of schema then replication should align them, but I am not familiar enough with which combinations and setup procedures are supported in IPA

Comment 12 Sankar Ramalingam 2014-11-25 15:44:30 UTC
From DS stand point.. the verification is complete.

Enabled memberOf and Deref plugin

dn: cn=MemberOf Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on

dn: cn=Deref Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on

Restarted the dirsrv instance. Then, added a suffix called "dc=example,dc=com". Then added the following entries to the suffix.

dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example

dn: uid=user.9999,ou=Public,dc=example,dc=com
telephoneNumber: 989898199
mail: user.9999@redhat.com
uid: user.9999
givenName: user.9999
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: user.9999
cn: user.9999
userPassword: Secret123

dn: ou=Private,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
ou: Private

dn: ou=Public,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
ou: Public

dn: cn=g2,ou=Private,dc=example,dc=com
objectClass: groupofnames
objectClass: top
member: uid=user.9999,ou=Public,dc=example,dc=com
cn: g2

dn: cn=g2,ou=Public,dc=example,dc=com
member: uid=user.9999,ou=Public,dc=example,dc=com
objectClass: groupofnames
objectClass: top
cn: g2

dn: uid=user.9993,ou=Public,dc=example,dc=com
telephoneNumber: 989898199
mail: user.9999@redhat.com
uid: user.9993
givenName: user.9993
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: user.9993
cn: user.9993
userPassword: Secret123


As Directory Manager user, the ldapsearch returns memberof entries from both public and private groups.

dn: uid=user.9999,ou=Public,dc=example,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAADLMIQAAABgBAhtZW1iZXJvZgQiY249Z
 zIsb3U9UHJpdmF0ZSxkYz1leGFtcGxlLGRjPWNvbaCEAAAALDCEAAAAJgQLb2JqZWN0Y2xhc3MxhA
 AAABMEDGdyb3Vwb2ZuYW1lcwQDdG9wMIQAAABfBAhtZW1iZXJvZgQhY249ZzIsb3U9UHVibGljLGR
 jPWV4YW1wbGUsZGM9Y29toIQAAAAsMIQAAAAmBAtvYmplY3RjbGFzczGEAAAAEwQMZ3JvdXBvZm5h
 bWVzBAN0b3A=
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g2,ou=Private,dc=
 example,dc=com

# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g2,ou=Public,dc=e
 xample,dc=com

memberof: cn=g2,ou=Private,dc=example,dc=com
memberof: cn=g2,ou=Public,dc=example,dc=com
------

Where as, for normal user, the ldapsearch returns only the memberof entries only from public group. Hence, marking the bug as Verified.

Comment 13 Sankar Ramalingam 2014-11-25 15:45:50 UTC
ldapsearch as normal user...

ldapsearch -x -p 1989 -h localhost -D "uid=user.9993,ou=public,dc=example,dc=com" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof

# user.9999, Public, example.com
dn: uid=user.9999,ou=Public,dc=example,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABlMIQAAABfBAhtZW1iZXJvZgQhY249Z
 zIsb3U9UHVibGljLGRjPWV4YW1wbGUsZGM9Y29toIQAAAAsMIQAAAAmBAtvYmplY3RjbGFzczGEAA
 AAEwQMZ3JvdXBvZm5hbWVzBAN0b3A=
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g2,ou=Public,dc=e
 xample,dc=com

memberof: cn=g2,ou=Private,dc=example,dc=com
memberof: cn=g2,ou=Public,dc=example,dc=com

Comment 15 errata-xmlrpc 2015-03-05 09:36:48 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.

https://rhn.redhat.com/errata/RHSA-2015-0416.html


Note You need to log in before you can comment on or make changes to this bug.