As as sys admin utilizing FreeIPA (or Rather Red Hat IdM) I have noticed that when creating a posix group it is possible to use the GID of an existing group and no error or warning is presented when this action occurs. While normally we would script this action as we know a script can sometimes get the wrong input or a group being renames with the same GID with the old group being present.
When creating a posix group in FreeIPA it is possible to create another group with the same GID in the environment.
ipa group-find --gid=990575066
3 groups matched
Group name: abc GID: 990575066
Group name: def GID: 990575066
Group name: ghi GID: 990575066
A warning or a full stop when trying to create a group with a GID that exists.
ipa-server-4.12.2-14.el9_6.1.x86_64 ipa-client-4.12.2-14.el9_6.1.x86_64 ipa-server-4.12.2-14.el9_6.1.x86_64 ipa-client-4.12.2-14.el9_6.1.x86_64 389-ds-base-2.6.1-10.el9_6.x86_64 package pki-ca is not installed krb5-server-1.21.1-8.el9_6.x86_64
Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.
Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting
There is currently no guardrails on this because only administrators can create new groups.
A possible solution is to add a uniqueness plugin configuration that would prevent non-unique gidNumber values. However, it might affect autogenerate feature as that is done by assigning '-1' to the gidNumber (or uidNumber).
Are you willing to experiment and add such a uniqueness plugin setup?
Thank you for your reply Alexander,
Just to give you a little more insight on the use case.
We use this IdM cluster for managing users and groups in our HPC = environment so there are quite literally over 3000+ project groups in = this environment. Currently how the work flow goes is that when a = project group is requested it creates the entry for the project group to = include GID in an external database (this is mainly for accountability = purposes). The script used to create the accounts reads that DB entry = and creates the group. So the autogenerate feature is not really = utilized in any capacity as the GID=E2=80=99s generated remain within = the range we define. So if this plugin simply checks for uniqueness and = will fail the task if a matching UID/GID is found then I would be more = than willing to try. My only other workaround has been adding a line in = the script: =E2=80=9Cipa group-find =E2=80=94gid=3D > /dev/null = 2>&1 ; if [ $? -eq 0 ]; then echo =E2=80=9CIdentical GID found=E2=80=9D; = exit 1;fi=E2=80=9D (That=E2=80=99s not the exact script but you get = the idea)=20
With regard to testing a plugin. By all means I would be more than happy = to be a lab rat for any plugins or feature you would like to test. Any = way I can contribute to the project and gain a greater depth on = knowledge on the system I am more than eager. I do have a QA cluster set = up for this purpose.
Thanks, David=20
On Sep 12, 2025, at 3:57=E2=80=AFAM, Alexander Bokovoy = pagure@pagure.io wrote: =20 =20 abbra added a new comment to an issue you are following: There is currently no guardrails on this because only administrators = can create new groups. =20 A possible solution is to add a uniqueness plugin configuration that = would prevent non-unique gidNumber values. However, it might affect = autogenerate feature as that is done by assigning '-1' to the gidNumber = (or uidNumber). =20 Are you willing to experiment and add such a uniqueness plugin setup? =20 To reply, visit the link below or just reply to this email https://pagure.io/freeipa/issue/9853
There is currently no guardrails on this because only administrators = can create new groups. =20 A possible solution is to add a uniqueness plugin configuration that = would prevent non-unique gidNumber values. However, it might affect = autogenerate feature as that is done by assigning '-1' to the gidNumber = (or uidNumber). =20 Are you willing to experiment and add such a uniqueness plugin setup?
-- David Lewellyn IT Systems Programmer Sr. Office of Information Technology https://oit.ncsu.edu/
Avent Ferry Technology Center NC State University C: (603) 560-5897
Open a Support Case https://ncsu.service-now.com/sp
All electronic mail messages in connection with State business that are = sent to or received by this account are subject to the NC Public Records = Law and may be disclosed to third parties.
@dlewell I created PR https://github.com/freeipa/freeipa/pull/7932 to test my idea.
Metadata Update from @abbra: - Issue assigned to abbra
Good Morning Alex,
I appreciate the PR. The one question I have is how would I implement = this plugin in a live non-production environment? Thank you, David
On Sep 15, 2025, at 4:05=E2=80=AFAM, Alexander Bokovoy = pagure@pagure.io wrote: =20 =20 The issue: Creating Posix Groups allows the creation of multiple = groups with the same GID of project: freeipa has been assigned to = abbra by abbra. =20 https://pagure.io/freeipa/issue/9853
Creating Posix Groups allows the creation of multiple = groups with the same GID
freeipa
abbra
You can take the content of that PR as a separate file and use ipa-ldap-updater to add:
ipa-ldap-updater
dn: cn=POSIX GID uniqueness,cn=plugins,cn=config default:objectClass: top default:objectClass: nsSlapdPlugin default:objectClass: extensibleObject default:cn: POSIX GID uniqueness default:nsslapd-pluginPath: libattr-unique-plugin default:nsslapd-pluginInitfunc: NSUniqueAttr_Init default:nsslapd-pluginType: preoperation default:nsslapd-pluginEnabled: on default:nsslapd-plugin-depends-on-type: database default:nsslapd-pluginId: NSUniqueAttr default:nsslapd-pluginVersion: 1.1.0 default:nsslapd-pluginVendor: Fedora Project default:nsslapd-pluginDescription: Enforce unique attribute values default:uniqueness-attribute-name: gidNumber default:uniqueness-subtrees: $SUFFIX default:uniqueness-exclude-subtrees: cn=compat,$SUFFIX default:uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX default:uniqueness-exclude-subtrees: cn=trusts,$SUFFIX default:uniqueness-across-all-subtrees: on default:uniqueness-subtree-entries-oc: posixAccount dn: cn=POSIX UID uniqueness,cn=plugins,cn=config default:objectClass: top default:objectClass: nsSlapdPlugin default:objectClass: extensibleObject default:cn: POSIX UID uniqueness default:nsslapd-pluginPath: libattr-unique-plugin default:nsslapd-pluginInitfunc: NSUniqueAttr_Init default:nsslapd-pluginType: preoperation default:nsslapd-pluginEnabled: on default:nsslapd-plugin-depends-on-type: database default:nsslapd-pluginId: NSUniqueAttr default:nsslapd-pluginVersion: 1.1.0 default:nsslapd-pluginVendor: Fedora Project default:nsslapd-pluginDescription: Enforce unique attribute values default:uniqueness-attribute-name: uidNumber default:uniqueness-subtrees: $SUFFIX default:uniqueness-exclude-subtrees: cn=compat,$SUFFIX default:uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX default:uniqueness-exclude-subtrees: cn=trusts,$SUFFIX default:uniqueness-across-all-subtrees: on default:uniqueness-subtree-entries-oc: posixAccount
Save it as, say, posix-uniqueness.update and then run the ipa-ldap-updater and restart the LDAP server:
posix-uniqueness.update
# ipa-ldap-updater ./posix-uniqueness.update Update complete The ipa-ldap-updater command was successful # systemctl restart dirsrv@MINIMAL-TEST
It looks like Pagure is interpreting some of the content as emojies, so I'm attaching the file: