New subject: [sssd PR#693][comment] SYSDB: Fall back to the MPG result of getgrgid search if the non-MPG search for override doesn't match anything

7 Nov 2018


      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

[sssd PR#693][opened] SYSDB: Fall back to the MPG result of getgrgid search if the non-MPG search for override doesn't match anything