ldap server + enforcing mode?

[Eric Paris]

On Thu, 2008-07-17 at 17:24 -0400, Robert Story wrote:
> I'm trying to get ldap (from openldap-servers-2.4.8-6) running in
> enforcing mode on a F9 server. When I try in enforcing mode, it fails.
> I've attaced the AVCs from the audit log, for 'service ldap start' in
> enforcing and permissive mode (with don't audit disabled), along with
> the avcs after the first round were passed through audit2allow and
> loaded..  After those are added and loaded, it starts up fine with no
> AVCs...
> 
> Should I file a bug report in bugzilla, or is this message sufficient?

Just to make sure it can't possibly get lost I usually file a BZ.  But:

Most of these are 'bogus'  The majority of them are some form of slapd
is trying to read files in /selinux and /etc/selinux.  I don't know why
slapd would be trolling around in either of those directories but I
can't imagine it would cause an actual problem in the operation of
slapd.

The real issue are these:
type=AVC msg=audit(1216329419.086:433): avc:  denied  { getattr } for  pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1216329419.220:434): avc:  denied  { getattr } for  pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1216329419.223:435): avc:  denied  { getattr } for  pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

These indicate to me that cacert.pem and slapd.pem were both created
in /tmp/and moved to /etc/openldap.  This is a labeling issue.  slapd
doesn't normally need access to files created in /tmp and since those
files have been moved you need to reset their attributes approprietely
to their new location.

restorecon -R -v /etc/openldap

After doing that can you send up the denials you get (with dontaudits)
and if it gives you any more trouble?

Also can you help us understand how these two .pem files were created
and how the got into /etc/openldap so we can try to fix this for others?

-Eric