Skip to content

Conversation

@alexey-tikhonov
Copy link
Member

No description provided.

If CAP_SETUID and/or CAP_SETGID are missing, 'krb5_child' will
skip operation that require those capabilities, namely any manipulations
with user ccache.

:packaging:This update makes it possible to not grant CAP_SETUID and CAP_SETGID
to 'krb5_child' binary in a situation where it is not required to store acquired
TGT after user authentication. Taking into account that it is already possible
to avoid using CAP_DAC_READ_SEARCH if keytab is readable by SSSD service user,
and usage of 'selinux_child' isn't always required, this allows to build a setup
with completely privilege-less SSSD to serve certain use cases. In particular,
this might be used to build a container running SSSD on OCP with a restricted
profile.
Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request modifies krb5_child to function correctly even when it lacks CAP_SETUID and CAP_SETGID capabilities. The changes involve removing these capabilities from Makefile.am and sssd.spec.in, and adding logic to krb5_child.c to detect their absence and skip operations that require them, such as updating the user's ccache. While the logic is generally sound, there's a minor logic issue in privileged_krb5_setup that could be simplified for better readability and to avoid redundant operations. Additionally, a new check in renew_tgt_child could be more robust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant