URL:
https://github.com/SSSD/sssd/pull/616
Title: #616: become_user: add supplementary groups so ad provider can access keytab
jhrozek commented:
"""
On Wed, Jul 11, 2018 at 11:42:44AM -0700, sumit-bose wrote:
Thank you for the patch it looks quite interesting.
I wonder if you wouldn't be able to achieve the same by setting the primary group of
the _sssd user to _keytab?
This would be my preference too. Or owning the keytab by
keytab.sssd. Alternatively, could the keytab file allow the sssd user to
read the contents with a POSIX ACL? (setfacl -m u:sssd:r /etc/krb5.keytab)
Additionally if you think that a secondary group is really necessary I
think it would be better to add a config option for this so that you can add
e.g. to the [domain/...] section 'secondary_gid = 12345'. This way /etc/group
(where is _sssd user is added to the _keytab group) is not a required part
of the SSSD configuration
I don't understand this part, I'm sorry. Do you propose that sssd_be
runs with some supplementary GIDs, but the responders don't? This makes
sense, but in general I'm not sure I like constructing some artificial
identity.
and the initgroups() call can be avoided because
it might be expensive at some places where become_user() is called.
This is a fair comment, although storing the sssd user in a remote
directory (which is realistically the only setup which might be slow)
doesn't strike me as the best idea.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/616#issuecomment-404281393