You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1153510
Description of problem:
netgroup lookups returned in lowercase with case_sensitive=preserving
Version-Release number of selected component (if applicable):
sssd-1.12.1-3.el7
How reproducible:
Always
Steps to Reproduce:
1. Add the following ldif to ldap server:
dn: cn=NetGroup_CS1,ou=Netgroups,dc=example,dc=com
objectClass: nisNetgroup
cn: NetGroup_CS1_Alias
cn: NetGroup_CS1
nisNetgroupTriple: (Host1.example.com,User1,example.com)
2. Confiure sssd with case_sensitive=false
3. Lookup netgroup
getent netgroup netgroup_cs1
Actual results:
# getent netgroup netgroup_cs1
netgroup_cs1 (Host1.example.com,User1,example.com)
Expected results:
Should not be lowercased.
Additional info:
I will close this as wontfix. Copy-pasting explanation from bugzilla bellow:
Hi,
I looked into this and I see this as NOTABUG. The reason is that we do not control the format of netgroup name in the getnetgr response packet. The packet only contains netgroup triples. The name of netgroup printed on the screen is always in the same case as the name entered by user when invoking getent.
So there is not much we can do about this, preserve and false will always behave the same with netgroups.
Michal
_comment0: I will close this as wontfix. Copy-pasting explanation from bugzilla bellow.
{{{
Hi,
I looked into this and I see this as NOTABUG. The reason is that we do not control the format of netgroup name in the getnetgr response packet. The packet only contains netgroup triples. The name of netgroup printed on the screen is always in the same case as the name entered by user when invoking getent.
So there is not much we can do about this, preserve and false will always behave the same with netgroups.
Michal
}}}
=> 1414097573608564
resolution: => wontfix
status: new => closed
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2459
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1153510
Comments
Comment from jhrozek at 2014-10-16 11:14:16
Reassigning to Michal. Please note this has a lower priority than the non-root sssd feature.
blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
owner: somebody => mzidek
review: True => 0
selected: =>
testsupdated: => 0
Comment from jhrozek at 2014-10-16 17:34:42
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.12.3
Comment from jhrozek at 2014-10-22 22:38:23
This upstream ticket was requesting by a downstream. Bumping the priority to make sure the ticket is closed as soon as possible.
priority: major => critical
Comment from mzidek at 2014-10-23 22:51:49
I will close this as wontfix. Copy-pasting explanation from bugzilla bellow:
Hi,
I looked into this and I see this as NOTABUG. The reason is that we do not control the format of netgroup name in the getnetgr response packet. The packet only contains netgroup triples. The name of netgroup printed on the screen is always in the same case as the name entered by user when invoking getent.
So there is not much we can do about this, preserve and false will always behave the same with netgroups.
Michal
_comment0: I will close this as wontfix. Copy-pasting explanation from bugzilla bellow.
{{{
Hi,
I looked into this and I see this as NOTABUG. The reason is that we do not control the format of netgroup name in the getnetgr response packet. The packet only contains netgroup triples. The name of netgroup printed on the screen is always in the same case as the name entered by user when invoking getent.
So there is not much we can do about this, preserve and false will always behave the same with netgroups.
Michal
}}}
=> 1414097573608564
resolution: => wontfix
status: new => closed
Comment from jhrozek at 2017-02-24 14:24:19
Metadata Update from @jhrozek:
The text was updated successfully, but these errors were encountered: