URL:
https://github.com/SSSD/sssd/pull/616
Title: #616: become_user: add supplementary groups so ad provider can access keytab
sumit-bose commented:
"""
On Wed, Jul 11, 2018 at 12:19:33PM -0700, Jakub Hrozek wrote:
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.
It is not about identity but giving the sssd_be the needed privileges to
access the file. But as said above my preferences would be to use the
primary gid or as you suggested POSIX ACLs to solve the issue.
> 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.
become_user() is also used in krb5_child to switch to the user trying to
log in to create the ccache with the right permissions.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/SSSD/sssd/pull/616#issuecomment-404281393
"""
See the full comment at
https://github.com/SSSD/sssd/pull/616#issuecomment-404285945