Bug 38796
|
Description
Janis Meybohm
# ./change_colliding-gids.py --help
Usage: change_colliding-gids.py [options]
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]
"v2"
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: /usr/lib/univention-pam/ldap-group-to-file.py --check_member 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 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. Commit: 64513 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. Done. Commits 4.0-3: 64575, 64576 Merge 4.1: 64577 YAML: 64579 Commit 64709 reduce the code and raises the readability. YAML: 64711 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: YAML OK: merge to UCS 4.1 OK: code review |