Fields changed

milestone: SSSD 1.0 => Iteration 6
owner: somebody => simo
priority: major => blocker

Fixed in d0682cba5cd82d7e0eaffe0a3a8e67fb2b782448

fixedin: => 0.5.0
resolution: => fixed
status: new => closed

This is back with today's build: sssd-0.6.0-0.2009092208git091df02.fc11.i586[[BR]]

group1009 is a member of group1010[[BR]]

# record 2
dn: name=group1009,cn=groups,cn=LOCAL,cn=sysdb
objectClass: group
name: group1009
gidNumber: 1009
createTimestamp: 1253641693
member: name=group1010,cn=groups,cn=LOCAL,cn=sysdb
distinguishedName: name=group1009,cn=groups,cn=LOCAL,cn=sysdb
# record 3
dn: name=group1010,cn=groups,cn=LOCAL,cn=sysdb
objectClass: group
name: group1010
gidNumber: 1010
createTimestamp: 1253641690
memberof: name=group1009,cn=groups,cn=LOCAL,cn=sysdb
distinguishedName: name=group1010,cn=groups,cn=LOCAL,cn=sysdb

doc: => 0
docupdated: => 0
resolution: fixed =>
status: closed => reopened
tests: => 0
testsupdated: => 0

group1010 is the parent group and it should have "member" attribute with group1009's dn.[[BR]]
group1009 is the child group and it should have "memberof" attribute with group1010's dn.[[BR]]

Reassigning to Jakub. This was broken in his new synchronous tools interface.

It's not simo's bug in the memberof plugin, it's due to a misunderstanding about how the -a (and -r) option is meant to work for sss_groupmod.

The way it should behave is {{{sss_usermod -a child1,child2 parent}}}. Currently, it is behaving as {{{sss_usermod -a parent1,parent2 child}}}. This needs to be put to rights.

fixedin: 0.5.0 =>
milestone: SSSD 0.5.0 => SSSD 0.6.0
owner: simo => jhrozek
status: reopened => new

Sorry I actually think there is no bug..the ldb listing seems absolutely correct to me.. It is not very clear from names like groupXXX, but:

sss_useradd child_user
sss_groupadd child_group
sss_groupadd parent_group
sss_usermod -a parent_group child_user
sss_groupmod -a parent_group child_group

Then in LDB:

dn: name=parent_group,cn=groups,cn=LOCAL,cn=sysdb
objectClass: group
name: parent_group
createTimestamp: 1253866024
gidNumber: 1002
member: name=child_user,cn=users,cn=LOCAL,cn=sysdb
member: name=child_group,cn=groups,cn=LOCAL,cn=sysdb
distinguishedName: name=parent_group,cn=groups,cn=LOCAL,cn=sysdb
dn: name=child_group,cn=groups,cn=LOCAL,cn=sysdb
objectClass: group
name: child_group
createTimestamp: 1253866020
gidNumber: 1001
memberof: name=parent_group,cn=groups,cn=LOCAL,cn=sysdb
distinguishedName: name=child_group,cn=groups,cn=LOCAL,cn=sysdb
dn: name=child_user,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: child_user
fullName: child_user
gecos: child_user
homeDirectory: /local/child_user
loginShell: /bin/ksh
createTimestamp: 1253866013
uidNumber: 1000
gidNumber: 1000
memberof: name=parent_group,cn=groups,cn=LOCAL,cn=sysdb
distinguishedName: name=child_user,cn=users,cn=LOCAL,cn=sysdb

I find myself corrected. Jenny, from the manpage:

sss_groupmod [options] GROUP

-a,--append-group GROUPS
   Append this group to groups specified by the GROUPS parameter. The
   GROUPS parameter is a comma separated list of group names.

This means that the GROUP option should be made a memberOf each option in the GROUPS list.
If we were doing it the other way around before, that was the bug. This behavior is consistent with the way the {{{-a}}} option works in {{{sss_usermod}}}

resolution: => invalid
status: new => closed
tests: 0 => 1

ah ha ... will update my tests!

Fields changed

tests: 1 => 0
testsupdated: 0 => 1

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1143

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.