Bug 1377241 - [RFE] ipa migrate-ds should provide option for creating UPG from posixGroup objectClass
Summary: [RFE] ipa migrate-ds should provide option for creating UPG from posixGroup o...
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Kaleem
Keywords: FutureFeature
: 1476943 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2016-09-19 09:39 UTC by gagriogi
Modified: 2019-01-31 22:49 UTC (History)
7 users (show)

Clone Of:
Last Closed:

Attachments (Terms of Use)
freeipa-pvoborni-0966-migrate-ds-user-private-group-support-if-UIDs-are-mi.patch (3.20 KB, patch)
2016-09-20 19:23 UTC, Petr Vobornik
no flags Details | Diff

Description gagriogi 2016-09-19 09:39:25 UTC
Description of problem:

When migrating users, provide an option to migrate groups as UPG

This is a clone of upstream ticket: https://fedorahosted.org/freeipa/ticket/4738

Comment 4 Petr Vobornik 2016-09-20 15:29:24 UTC
For reference, putting this to bz, so other people can see it:

UPG are managed entries created by "managed entries plug-in". AFAIK they
are created only on ADD of users (here I'm not sure, but docs suggest
that [1])

migrate-ds doesn't handle UPGs well. More specifically it
unconditionally stops creation of UPGs during migration of users by
adding the NO_UPG_MAGIC constant into user's description attribute.

It doesn't reflect UPG settings(enablement of UPG definition). But from
the code it seems that there was some intention to do it which didn't

It might be possible to work around the issue by removing following lines from migrate-ds plugin code
    # We don't want to create a UPG so set the magic value in description
    # to let the DS plugin know.
    entry_attrs.setdefault('description', [])

but it needs to be tested first, see comment in the commit below. Also it assumes that uidnumber==gidnumber and both are migrated.

This was added in https://fedorahosted.org/freeipa/ticket/2562 commit


Comment 5 Rob Crittenden 2016-09-20 17:39:39 UTC
Petr, removing those lines is only part of it.  You also need to be sure that no other users are members of the group before creating it as a private group (which can have no members). This needs to checked both via group membership and via the user primary group.

IIRC you are right, if the gid is different then I don't think it'll work using the managed entry plugin. That isn't to say it can't be faked by manually creating the group using pure ldap calls you're just getting close to no-man's land.

Comment 6 Petr Vobornik 2016-09-20 18:19:28 UTC
Actually the cloned upstream bug is not probably the right one for use case I was creating the workaround - IPA-IPA migration.

In migration from one IPA to another we are not changing POSIX groups into UPGs but rather we should not migrate UPGs and create new UPGs for users which had them(I assume that if GID==UID then there was an UPG)

I have a preliminary patch which does something like:

if upg_support_enambled and gid != uid
  prevent UPG create
  let managed entry plugin create UPG

This works only if UIDs are migrated.

It also doesn't cover other use cases like forced creation of UPGs for all users or creation of UPG after migration.

Comment 7 Petr Vobornik 2016-09-20 19:18:58 UTC
There was also a question when ipa migrate-ds created a group which looked like:

ipa group-show lbar --all --raw
  dn: cn=lbar,cn=groups,cn=accounts,dc=example,dc=test
  cn: lbar
  description: User private group for lbar
  gidnumber: 903000004
  ipaUniqueID: 5ced9f72-7f5f-11e6-a667-001a4a2314d1
  mepManagedBy: uid=lbar,cn=users,cn=accounts,dc=example,dc=test
  objectClass: ipaobject
  objectClass: top
  objectClass: mepmanagedentry
  objectClass: ipausergroup
  objectClass: posixgroup
  objectClass: groupofnames
  objectClass: nestedgroup

This can happen when UPGs are not created by managed entry plugin and migration is done with options 
   --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup

The reason is that UPG is a POSIX group(has posixgroup object class) and therefore is migrated but is normalized in a way that it gets also all the other object classes. It then presents itself incorrectly in Web UI, CLI...

To avoid it it is better to migrate with 
  --group-container=cn=groups,cn=accounts --group-objectclass=ipausergroup

Using ipausergroup will migrate also external groups but won't add additional object classed to UPGs.

Comment 8 Petr Vobornik 2016-09-20 19:23 UTC
Created attachment 1203005 [details]

Attaching a patch which does what I meant in comment 4 and comment 6

It will be later sent as upstream pull request.

Comment 9 Rob Crittenden 2016-09-20 19:24:43 UTC
I think there should probably be a separate option when doing IPA to IPA migration.

Comment 10 Rob Crittenden 2016-09-20 19:25:50 UTC
As for the patch, I don't think it's a safe assumption that the group is private just because the UID/GID match.

Comment 11 Petr Vobornik 2016-09-20 19:39:44 UTC
True, but if there is an overlap with other POSIX group then the other won't be migrated(will be reported) unless you pass --group-overwrite-gid which then changes it's GID (might not be wanted). 

The reason why it happens is that users are migrated first, UPGS are create at user creation and then migration of the other group will fail on "existing GID check".

Possible alternative solution might be to make it configurable via some option e.g.: --upg-mode={matching-ids,force-upgs,ńo-ups}

but I'd not like to over-engineer it.

As for comment 9 - special option for IPA-IPA migration - best to be solved in https://fedorahosted.org/freeipa/ticket/3656

Comment 13 Petr Vobornik 2016-09-30 12:36:41 UTC
Upstream ticket:

Comment 15 Petr Vobornik 2017-02-23 16:00:28 UTC
The bugzilla doesn't have high enough priority in comparison to other IdM bugs/RFEs for 7.4. Moving to next release. Without sufficient justification it can be moved again later.

Comment 16 Petr Vobornik 2017-08-11 16:32:51 UTC
*** Bug 1476943 has been marked as a duplicate of this bug. ***

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