Bug 1077695

Summary: Negative value for parameters in sssd.conf shows different value in logs
Product: Red Hat Enterprise Linux 7 Reporter: Kaushik Banerjee <kbanerje>
Component: sssdAssignee: SSSD Maintainers <sssd-maint>
Status: CLOSED DEFERRED QA Contact: Kaushik Banerjee <kbanerje>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.0CC: grajaiya, jgalipea, jhrozek, lslebodn, mkosek, pbrezina, preichl
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-24 11:25:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kaushik Banerjee 2014-03-18 12:39:49 UTC
Description of problem:
Negative value for parameters in sssd.conf shows 4294966296 in logs

Version-Release number of selected component (if applicable):
1.11.2-54.el7

How reproducible:
Always

Steps to Reproduce:
1. Add an option "ldap_idmap_range_min=-1000" in sssd.conf
2. Restart sssd

Actual results:

Domain log shows:
[sssd[be[ADTEST]]] [sdap_idmap_init] (0x0010): Invalid settings for
range selection: [4294966296][2000200000][200000]

Expected results:


Additional info:
Logging as a low priority bug. Part of negative tests in our automation suite.

Comment 1 Kaushik Banerjee 2014-03-18 12:41:04 UTC
Also adding a comment from Jakub on discussing this issue:

This is a peculiarity of C and I'm not sure there's much we can sensibly
do about this. In C, the info on whether the value is signed or unsigned
is not stored anywhere except the type of the variable. So 0xFF can be
either -1 or 255 depending on how you look at the bytes.

What we should do instead is implement the ding-libs validator which
would disallow negative values for parameters that can only hold
positive values.

Comment 3 Lukas Slebodnik 2014-03-18 13:08:08 UTC
Manual pages says:
Specifies the lower bound of the range of POSIX IDs to use for
mapping Active Directory user and group SIDs.

And POSIX IDs are unsigned integers.

I think it is a use case for sssd_check BZ1072458

Comment 4 Jakub Hrozek 2014-03-20 14:48:09 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/416

Comment 5 Jakub Hrozek 2014-03-20 14:49:38 UTC
(In reply to Lukas Slebodnik from comment #3)
> Manual pages says:
> Specifies the lower bound of the range of POSIX IDs to use for
> mapping Active Directory user and group SIDs.
> 
> And POSIX IDs are unsigned integers.
> 
> I think it is a use case for sssd_check BZ1072458

I agree this should be solved at a different level. I've linked this bugzilal with a ticket to implement the sssd.conf validator.

Comment 6 Martin Kosek 2015-04-24 11:25:08 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.