[Freeipa-users] RHEL 6.4 ipa-client install on ipa member server

Dale Macartney dale at themacartneyclan.com
Mon Feb 25 11:06:09 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 02/25/2013 10:58 AM, Jakub Hrozek wrote:
> On Mon, Feb 25, 2013 at 10:30:44AM +0000, Dale Macartney wrote:
>>>> What state is your SELinux in? Permissive/Enforcing/Disabled ?
>> Another fail on my part. Works fine in permissive mode.
>>
>
> No, the SSSD should be working out of the box with SELinux Enforcing.
>
>> AVC denials listed below..
>>
>> type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for
>> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246
>> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
>> type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for
>> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246
>> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
>> type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for
>> pid=2271 comm="sshd" path="/var/lib/sss/mc/passwd" dev=dm-0 ino=914246
>> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
>
> ^ This is SElinux denying access to the fast in-memory cache.
>
>> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
>> type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for
>> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>> type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for
>> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>> type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for
>> pid=2275 comm="krb5_child" path="/etc/selinux/config" dev=dm-0
>> ino=392854 scontext=system_u:system_r:sssd_t:s0
>
> Interesting, I'm not aware of any code in the krb5 child process that
> would do anything selinux-related. I wonder if libkrb5 might be the
> culprit..rpm says it *is* linked against libselinux as well.
>
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
>> pid=1380 comm="sssd_pam" name="logins" dev=dm-0 ino=392943
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
>> type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name }
>> for pid=1380 comm="sssd_pam" name="adminoTfIUQ"
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
>> type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for
>> pid=1380 comm="sssd_pam" name="adminoTfIUQ"
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
>> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>> type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name }
>> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
>> type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for
>> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>> type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for
>> pid=1380 comm="sssd_pam" name="admin" dev=dm-0 ino=392951
>> scontext=system_u:system_r:sssd_t:s0
>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
>
> This is SSSD trying to write the user login mapping.
>
> What version is your selinux-policy?
>
> Was your system properly labeled?
>
> Does restorecon -Rvv /etc/selinux help?
Interesting, after using restorecon, yes it now allows a successful
login. I am curious how the contexts would have become incorrectly set
as the machine was provisioned with a rather trivial kickstart.

output of restorecon is below.

[root at workstation01 ~]# restorecon -Rvv /etc/selinux/
restorecon reset /etc/selinux/targeted/logins context
system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0
restorecon reset /etc/selinux/targeted/logins/admin context
system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0
[root at workstation01 ~]#

selinux policy version 3.7.19-195.el6_4.1


>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRK0WgAAoJEAJsWS61tB+qnnYQAJJgXcVUUU2DdOUFR34GeU97
NgAoJfbPdL8wtXWT+qqnwdGWRRFO4fgfZF6DBh21suW0f4PrNiv8PPmq/jSXqbF6
K+PwT/txjU4nvm+9j2uvJGvgysisVXwVXkUHGlyljG9FyrilaLi0rnk2cuZ0LdC2
Zwt0x9u1f+yXU4l4IGWJNxW26C+wr5oAZvpCbzGO19ODCctBFvGTox0yFVCE1tB2
wFSIT/B8iLgSQeJgUnJsqXFpiqtGAAg7eAErqsMv1XbuC0RMwDCWcbZEgn24jp5D
gE+Drx3fVZEZWFtdJBTQW6UICOdo+51aS5HtqpAevFod78CbMNJNFrEfV5j3uwhY
xP6CjpJfxGbxXErVZJ/NTFATzcqt7C7Hy0WboSlCWrDYGsnpsFD3QbGJznWvORed
LTwqPRlt/+qN+mZu+Kq+4qYtNxKazK7KcNqoIP5MncnMY7qOhy+PYlKNp61FFbSM
dzOJXsVhmM7bZnFO8p0bANP5Mp9pY2Z6wuTIMN2LPz7FgceJJGoBn0gk60H/YmZi
/L9vNtmPXRzOFs8gQA4E0/yFRhOBKPEydxjXjXBr0cDGi7V0GZxHBPpZnKpU5iXA
6BBoc+uA9+UYxRJ5Li36L/ZIDAuPUl7li7aAgclTop0i+Nc4lc50wMMlBgVK7QUw
HOiAP+SPML/f9sDpM3/n
=4zva
-----END PGP SIGNATURE-----




More information about the Freeipa-users mailing list