Hi, I wrote a design document for the work tracked in https://pagure.io/SSSD/sssd/issue/3822 which is about a ‘hybrid’ MPG mode where the private group would be generated only for users who do not have a gidNumber set explicitly: https://pagure.io/SSSD/docs/pull-request/72
For your convenience, the document in the RST format is also pasted below: Hybrid Private Groups for LDAP and AD domains ============================================= Related ticket(s): ------------------ https://pagure.io/SSSD/sssd/issue/3822 Problem statement ----------------- This change will augment the ``auto_private_groups`` option which currently is a boolean option with a third mode that would, for users who do have the ``gidNumber`` attribute set return the original group, but for users who have no ``gidNumber,`` autogenerate a user-private group. Use cases --------- This change is mostly useful for backwards compatibility in environments that used to manually set a ``gidNumber`` and need to retain the same primary GID number, but for newly added user, autogenerate the user private group from the ``uidNumber.`` Please see the "How to test" section for an example. Overview of the solution ------------------------ Internally, this hybrid domain would work as a MPG domain, so as if ``auto_private_groups`` was set true. The difference would be when returning the entries. In the hybrid model, if the user being returned had an original GID, this original GID would be used. Otherwise, a primary group generated from the UID would be returned. Care must be taken in the getgrnam and getgrgid calls to not return the autogenerated group if requested for a user who also has the originalGID set. Implementation details ---------------------- As said above, for the most part, the hybrid domain would work in a similar manner as a domain that had ``auto_private_groups=true`` set in the config file. This means, that the ``uidNumber`` and ``gidNumber`` attributes in the sysdb cache are always set to the same value, but in case the original entry in LDAP did have a gidNumber stored, that original value is also stored in the cache using the ``origPrimaryGroupGidNumber`` attribute. The purpose of this attribute is to be able to return the original primary GID as a supplemetary group so that any resources owned by this ID are still accessible to the user. We will take advantage of this attribute when returning the user object during ``getpwnam`` (keep in mind that ``struct passwd`` that the ``getpwnam`` call returns also contains the primary GID number), initgroups and also for a special case during the ``getgrgid`` and ``getgrnam`` calls. During the getpwnam call, the code will check whether the user being returned has the ``origPrimaryGroupGidNumber`` or not. If it does, its value would be returned as the GID number, otherwise the ``gidNumber`` attribute would be used. A similar logic will be implemented in the initgroups call, with the additional caveat that if the ``origPrimaryGroupGidNumber`` exists, it wouldn't be returned as another secondary group. For group requests in a domain where the user private groups are completely managed, SSSD would search the whole combined user and group space and return group objects based on user objects in the cache. The hybrid domain must behave a little differently here. When a request for a user-private group comes, the ``getgr*`` call in a hybrid domain should first try to search group objects only. If there is no match, then also the user objects need to be searched, but only those user objects that have no ``origPrimaryGroupGidNumber`` set can be returned as a private groups. Reusing the example above, ``getgrnam("hybriduser")`` would return a group object inferred from the user object, but ``getgrnam("posixuser")`` would not return anything. Configuration changes --------------------- Since we are adding a new option value to the existing ``auto_private_groups`` call, the option must internally be converted from boolean to a string with three possible values. We would retain ``true`` and ``false`` for backwards compatibility but add a third option value ``hybrid.`` How To Test ----------- Considering these two partial LDIFs:: cn=posixuser,dc=example,dc=com uidNumber: 1234 gidNumber: 5678 cn: posixuser gecos: posix user homeDirectory: /home/posixuser loginShell: /bin/sh cn=hybriduser,dc=example,dc=com uidNumber: 2345 cn: hybriduser # note: no gidNumber attribute gecos: hybrid user homeDirectory: /home/hybriduser loginShell: /bin/sh The getpwnam output for these two users would be:: $ getent passwd posixuser posixuser:*:1234:5678:posix user:/home/posixuser:/bin/sh $ getent passwd hybriduser hybriduser:*:2345:2345:hybrid user:/home/hybriduser:/bin/sh _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org