Univention Bugzilla – Bug 38796
ensure uidNumber and gidNumber do not collide when add/mod user or group
Last modified: 2018-10-08 21:49:05 CEST
We should ensure that a uidNumber is not used as gidNumber and vice versa as that may lead to problems with samba4 idmap ldb.
# ./change_colliding-gids.py --help
Usage: change_colliding-gids.py [options]
-h, --help show this help message and exit
-d FILE, --dir=FILE run chgrp recursivly on directory, expects change
information from file with -i
-i FILE, --infile=FILE
read group changes from FILE
-o FILE, --outfile=FILE
write group changes to FILE
-l, --ldap Modify GIDs of groups in LDAP, expects change
information from file with -i [default=off].
-v, --verbose write about current action [default=on].
# ./change_colliding-gids.py -o out.txt
# ./change_colliding-gids.py -i out.txt -l
# ./change_colliding-gids.py -i out.txt -d /home/
Console output omitted. Details logs go to /var/log/changegrp/$DATE.log
PAM caches for about 10min. A reboot is the most secure thing to do after changing the GIDs.
Created attachment 6987 [details]
find colliding gids, change them in LDAP and on disk
The attachment is for a support ticket to help a customer who manually set UIDs to match those of an existing system. But the problem is a general one and should be addressed in UDM:
If the same uidNumber and gidNumber exist in a domain, problems occur. With uids starting at 2000 and gids starting at 5000 it takes just 3000 users to run into potential problems. UDM should make sure this doesn't happen. My guess is this should be done wherever ualloc.request(lo, position, 'gidNumber') (and uidNumber) goes.
Created attachment 6990 [details]
The problem with the first version was, that it did change GIDs of all groups it could find duplicate IDs. But it happens, that a group is used by computer accounts, and those don't show up in users/user and thus were not modified. So suddenly the AppCenter and other functionality ceased to work, because the computer accounts had primaryGroups that didn't exist anymore.
While it would be possible to include computer accounts in the chgrp operation, it is not what this script is intended for, so I decided to exclude groups that are not intended for users.
This version has a blacklists for user and group accounts that should not be touched. The list was compiled on a pristine UCS 4.0 with Samba4. The only not-blacklisted default group is "Domain Users".
The new '-b' switch makes it print the blacklisted users and groups.
Der Gruppen Cache kann neu aufgebaut werden durch den Aufruf von:
The code to reserve UIDs and GIDs before using them has been adapted to make sure no two UIDs and GIDs are the same.
Commits: 63551 - 63554
Merge to 4.1: 63555
YAML (r63557): 2015-09-09-univention-directory-manager-modules.yaml
See also Bug 26383.
It is still possible to create a collision by explicitly modifying a user/group, requesting specific UID/GID, with UDM on the command line. Such a UDM call should fail.
Deliberate collisions of uidNumbers and gidNumbers are now forbidden, when using udm. They can be allowed if UCRV directory/manager/uid_gid/uniqueness=no.
YAML (64514): 2015-09-09-univention-directory-manager-modules.yaml
Please consider users without uidNumber by checking:
if 'posix' in self.options or 'samba' in self.options
Please outsource the same code into a method to remove code duplication.
You can remove the configRegistry.load() as this might cause performance problems if you edit e.g. 1000 users or groups. We never reload UCR variables in a handler. A univention-cli-server restart is better if the variable gets changed which should not occur often.
Use new style raising.
Commits 4.0-3: 64575, 64576
Merge 4.1: 64577
Commit 64709 reduce the code and raises the readability.
OK: creation of users/groups still work
OK: creation of user with existing uidNumber/gidNumber == uidNumber fails
OK: creation of group with existing uidNumber/gidNumber == gidNumber fails
OK: merge to UCS 4.1
OK: code review