URL: https://github.com/SSSD/sssd/pull/693 Author: jhrozek Title: #693: SYSDB: Fall back to the MPG result of getgrgid search if the non-MPG search for override doesn't match anything Action: opened
PR body: """ Commit cf4f5e031ecbdfba0b55a4f69a06175a2e718e67 changed the logic of getgrgid (and getpwnam, so far this patch only touches getgrgid) in the sense that if looking up a GID in a MPG domain, the code checks if the GID was overriden and if yes, it mandates that the overriden GID resolves to a group by falling back to a non-MPG search.
This breaks the following use-case: $ ipa idoverrideuser-add --uid=13133 --gidnumber=13133 'Default Trust View' user@domain
Most importantly, I'm on the fence about whether the current behaviour is a bug or not. In general, I would have expected that if a primary GID is overriden, you more or less break the MPG model, and then it's fair from SSSD to make sure the GID number resolves to an entry. But apparently our users were relying on the old behaviour where you can set the primary GID with an override and then still resolve the primary group by ID to the user entry.
So the patch in the PR is just a quick hack which sort of falls back to using the user entry as the group if the overriden GID doesn't resolve to anything.
Should we support this use-case at all? Should we maybe limit it to cases where the UID and GID are the same? """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/693/head:pr693 git checkout pr693