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.
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...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Thomas Woerner
QA Contact: ipa-qe
URL:
Whiteboard:
: 1476943 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-19 09:39 UTC by gagriogi
Modified: 2023-10-06 17:33 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-10 06:52:55 UTC
Type: Bug
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-9588 0 None None None 2023-03-23 12:34:09 UTC
Red Hat Issue Tracker RHELPLAN-34437 0 None None None 2021-09-09 11:59:11 UTC

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
happen.


Workaround:
It might be possible to work around the issue by removing following lines from migrate-ds plugin code
(/usr/lib/python2.7/side-packages/ipalib/plugins/migration.py):
    # 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', [])
    entry_attrs['description'].append(NO_UPG_MAGIC)

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
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=b55c98f1c5b0d46aba3f1792ebd8ecc059173b6a


[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/managed-entries-attributes.html
[2]
https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA

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
else 
  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:11 UTC
Created attachment 1203005 [details]
freeipa-pvoborni-0966-migrate-ds-user-private-group-support-if-UIDs-are-mi.patch

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:
https://fedorahosted.org/freeipa/ticket/4738

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. ***

Comment 21 Amy Farley 2019-08-16 14:17:39 UTC
Because of where RHEL 7 is in lifecycle, moving this to RHEL 8 as this is a complex issue to fix.

Comment 22 Petr Čech 2020-07-10 06:52:55 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. The request was cloned to the upstream tracker a long time ago (see link to the upstream ticket above), but it was unfortunately not given priority either in the upstream project, nor in Red Hat Enterprise Linux.

Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.

To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you. Please note that you can still track this request or even offer help in the referred upstream Pagure ticket to expedite the solution.


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