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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
