Bug 1439951

Summary:	SELINUX_getpeercon failed [-1][Unknown error -1].
Product:	Red Hat Enterprise Linux 7	Reporter:	fjayalat
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Madhuri <mupadhye>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.3	CC:	fidencio, grajaiya, jhrozek, lslebodn, mkosek, mzidek, nsoman, pbrezina, sgoveas, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.15.1-1.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 09:04:18 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 fjayalat 2017-04-06 23:39:36 UTC

Description of problem:

Creating a clone from this upstream bugzilla :
https://pagure.io/SSSD/sssd/issue/3094

Customer description of the issue :

Since rolling out Redhat IdM client configuration to our RHEL 6 and 7 fleet, various users have been experiencing issues logging in using an Active Directory account via SSH. It seems to have only effected RHEL 7 so far. The user doesnt get prompted for a password, the SSH connection simply gets closed. Increasing the debug level has shown the following error:

SELINUX_getpeercon failed [-1][Unknown error -1].

I can confirm that we have selinux set to disabled on all hosts:
SELinux status:                 disabled

A restart of SSSD seems to resolve the issue. I have not been able to pin-point a time or reason that this occurs. It seems to be around 14 days or more after a SSSD restart.

I have identified this article, which shows that this issue *MIGHT* be resolved in SSSD version 1.14.1, we are currently on version 1.14.0.

https://www.redhat.com/archives/freeipa-users/2016-August/msg00322.html


Version-Release number of selected component (if applicable):
sssd-1.14.0-43


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Jakub Hrozek 2017-04-07 06:41:53 UTC

This is indeed fixed upstream, but it's really just an annoying debug message that shows up if selinux is disabled. This commit shows the change done upstream:
https://github.com/SSSD/sssd/commit/4b9ee02b1f5252b2a116adf0c0c6c7a4722bb2cf

(No C knowledge required to read that commit)

So if the customer is really seeing some degradation of functionality, I doubt it is caused by this issue.

Comment 3 Jakub Hrozek 2017-04-07 06:42:50 UTC

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3094

Comment 13 Madhuri 2017-06-01 11:34:54 UTC

Tested with:
sssd-1.15.2-37.el7.x86_64.
window 2012 r2.

Steps followed during verification:
1) Install sssd packge.
2) Join ad server with # net ads command.
3) Authenticate the ad user.

# net ads info
LDAP server: 10.65.210.46
LDAP server name: adserver.example.com
Realm: EXAMPLE.COM
Bind Path: dc=EXAMPLE,dc=COM
LDAP port: 389
Server time: Thu, 01 Jun 2017 00:12:38 EDT
KDC server: 10.65.210.46
Server time offset: -19801
Last machine account password change: Thu, 01 Jun 2017 05:00:45 EDT

# net ads user
Administrator
Guest
krbtgt
sshd
cyg_server1
madhuri
new_user


# getent passwd new_user
new_user:*:217801119:217800513:new_user:/home/EXAMPLE.COM/new_user:/bin/bash


# ssh -l new_user localhost
new_user@localhost's password: 
Creating home directory for new_user.
[new_user@client_mul ~]$ pwd
/home/EXAMPLE.COM/new_user
[new_user@client_mul ~]$ exit
logout
Connection to localhost closed.

Comment 14 Lukas Slebodnik 2017-06-02 15:45:42 UTC

Previous steps does not cover this bug.
But on the other hand we just changed debug_level for an annoying debug message.

Comment 18 Madhuri 2017-06-05 13:08:59 UTC

Tested with
sssd-1.15.2-37.el7.x86_64

Steps followed during verification:
1) Setup sssd client against AD server.
2) selinux set to disabled

# sestatus -v
SELinux status:                 disabled

3) Set debug_level = 0x0080 in sssd.conf

# egrep debug_level /etc/sssd/sssd.conf
debug_level = 0x0080
debug_level = 0x0080
debug_level = 0x0080
debug_level = 0x0080

4) Delete the log and restart the sssd service.

# service sssd stop; rm -rf /var/log/sssd/*; service sssd start

5) # id Administrator
uid=217800500(administrator) gid=217800513(domain users) groups=217800513(domain users),217800520(group policy creator owners),217800519(enterprise admins),217800512(domain admins),217800518(schema admins),217800572(denied rodc password replication group)

6) Check error message in sssd log
# grep 'SELINUX' . -ir
./sssd_nss.log:(Mon Jun  5 08:58:51 2017) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
./sssd_nss.log:SELINUX_getpeercon failed [92][Protocol not available].
./sssd_nss.log:Please, consider enabling SELinux in your system.

With 'debug_level = 0x0080' printing the error message but not with 'debug_level = 0x0020'.

Comment 22 errata-xmlrpc 2017-08-01 09:04:18 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2294