On Tue, Oct 02, 2012 at 10:53:54AM -0400, Stephen Gallagher wrote:
> On 10/02/2012 09:32 AM, Jakub Hrozek wrote:
>> If the SSSD domain is running with SSSDBG_TRACE_ALL, then we also set
>> Kerberos tracing with krb5_set_trace_filename.
>> There's one catch, though. The krb5_child and ldap_child logs are only
>> writable by root, but the krb5_child process drops privileges to the
>> user before priming his ccache. With this patch applied and debug_level
>> set to 10, the krb5_child process doesn't drop privileges..
>> I personally think that's fine, because running with debug_level 10
> SSSDBG_TRACE_ALL is actually level 9
>> provides a LOT of debugging so it should only be configured for
>> debugging anyway. Also we don't drop privileges in other scenarios..
> Well, this really isn't acceptable. The reason we drop privileges is
> because that's the only way to create the credential cache with the
> proper ownership (and handle SELinux transitions).
>> I could maybe add a new param to the child or add heuristics to drop
>> privileges after the debugging is set but that seemed like an over
>> engineering when this feature is only useful for hardcode debugging.
> I'd rather add a new debug level for this, if it's really the
> solution we're going to take, I want it to be called out in the
> manpage that if you set debug_level = 10 (or 0x8000) that you are
> accepting that the added debug information comes at a cost,
> specifically that it will result in unexpected behavior post-login
> (wrt access to the credential cache). Because this is now owned by
> root, it's nontrivial to restore access after this as well.
> I would much prefer finding a different way to do the logging;
> perhaps we could have the krb5_child log to krb5_child.$USER.log
You're right, that wasn't my brightest patch.
I've checked the krb5 API again and used krb5_set_trace_callback() to
proxy krb5 tracing to our DEBUG macros.
sssd-devel mailing list
Associate Software Engineer
Red Hat Czech
loc: 1/5C Brno 1 office
irc: okos @ #brno