This is part 2 of an 8 part post covering the process used to trace down and correct a problem with semanage login record group matching. If you have not already read the previous parts, you may want to start at the beginning

Problem Discovery

A newly hired individual, let's say "Alice", was being provisioned into the environment. This is a common and highly automated procedure. Among many other actions, the provisioning process placed Alice into a system group, let's say "ft-financial-accounting", along with all of the other existing users in the "ft-financial-accounting" group. In this particular situation, a new group was being relied upon, but that was nothing terribly unusual.

Near the end of the provisioning process, a sanity check is run to confirm that everything that should have been done was in fact accomplished and the account tool's idea of what should be actually matches with the system's reality. This sanity check turned up a problem, the user ('alice') existed and was in the proper LDAP groups, but could not access its own home directory.

Basic checking confirmed that the home directory was in fact created and had been setup with the proper discretionary access control (DAC) permissions. Additionally, the system being checked was pulling down user and group information correctly and Alice had been assigned to the intended groups. That left a mandatory access control (MAC) issue, aka selinux.

A quick id -a later and the base problem became apparent. Alice looked like:

uid=100000(alice) gid=100000(alice) groups=100000(alice),100001(ft-financial-accounting) context=user_u:user_r:user_t:s0-s0:c0

instead of something like:

uid=100000(alice) gid=100000(alice) groups=100000(alice),100001(ft-financial-accounting) context=user_u:user_u:user_u:SystemLow-finance

The question was, why. User and group information was correct. Alice existed as a user and was a member of the "ft-financial-accounting" group. While it had not been touched, all looked correct with:

$ semanage login -l | grep '%ft-financial-accounting'
%ft-financial-accounting      user_u        SystemLow-finance

Clearly something was wrong with the system group to selinux user mapping, although at this point it was not clear where the problem originated. SSSD, having just been patched to fix a different group related problem was suspected, but why then would id be returning the right groups?

Next up, part 3: Finding a reproducer.