Bug 1439951 - SELINUX_getpeercon failed [-1][Unknown error -1].
Summary: SELINUX_getpeercon failed [-1][Unknown error -1].
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Madhuri
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-06 23:39 UTC by fjayalat
Modified: 2020-12-14 08:28 UTC (History)
10 users (show)

Fixed In Version: sssd-1.15.1-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:04:18 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4127 0 None closed SELINUX_getpeercon failed [-1][Unknown error -1]. 2021-02-09 04:13:19 UTC
Red Hat Product Errata RHEA-2017:2294 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

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@example.com
new_user@EXAMPLE.COM:*:217801119:217800513:new_user:/home/EXAMPLE.COM/new_user:/bin/bash


# ssh -l new_user@example.com localhost
new_user@example.com@localhost's password: 
Creating home directory for new_user@example.com.
[new_user@EXAMPLE.COM@client_mul ~]$ pwd
/home/EXAMPLE.COM/new_user
[new_user@EXAMPLE.COM@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@EXAMPLE.COM
uid=217800500(administrator@EXAMPLE.COM) gid=217800513(domain users@EXAMPLE.COM) groups=217800513(domain users@EXAMPLE.COM),217800520(group policy creator owners@EXAMPLE.COM),217800519(enterprise admins@EXAMPLE.COM),217800512(domain admins@EXAMPLE.COM),217800518(schema admins@EXAMPLE.COM),217800572(denied rodc password replication group@EXAMPLE.COM)

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


Note You need to log in before you can comment on or make changes to this bug.