On 06/16/2010 06:04 AM, Rob Crittenden wrote:
In IPA v2 I'm getting the following SELinux AVCs from ns-slapd:
type=AVC msg=audit(1276693069.494:16808): avc: denied { getattr } for
pid=16334 comm="ns-slapd" path="/var/tmp/ldap_496" dev=sda1
ino=180255
scontext=unconfined_u:system_r:dirsrv_t:s0
tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file
type=AVC msg=audit(1276693069.494:16809): avc: denied { unlink } for
pid=16334 comm="ns-slapd" name="ldap_496" dev=sda1 ino=180255
scontext=unconfined_u:system_r:dirsrv_t:s0
tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file
I'm seeing a related error in my Apache logs:
[Wed Jun 16 08:57:49 2010] [error] ACIError: Insufficient access:
SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (Cannot create replay cache file
/var/tmp/ldap_496: File exists) Invalid credentials
The context is we create an ldapi connection during Apache startup. We
use GSSAPI and a keytab to authenticate.
At this point I'm not sure if this is an issue with 389-ds or IPA.
I've never seen this before. It looks like DS is trying to remove
/var/tmp/ldap_496, but it's not allowed to. Apache (GSSAPI libs really)
then has a problem since this file already exists.
I'm not really familiar with this replay cache file. It must be created
by the GSSAPI or Kerberos libs directly. Are you doing something new
related to how your using GSSAPI and DS, or was this working before?
Are you able to run restorecon on /var/tmp/ldap_496 to make the problem
go away?
I've got the latest selinux-polixy installed:
selinux-policy-3.6.32-116
rob
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel