[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5507) Ldap clients leak file descriptors



I've no idea how SELinux works, so I'm not up to testing any of what
I'm saying here myself, but some notes follow anyway.  Please clarify:

> On system protected by SELinux, when an application with active LDAP
> connection tries to exec() binary with different security context,
> SELinux inspects all opened filedescriptors, including the ldap one,
> and denies access to the ones, which do not conform active policy (the
> executed binary is not authorized to contact LDAP servers).  Users are
> then annoyed by security warnings in the logs.

More to the point, some of those security warnings may indicate real
security problems.  Bind with password, exec some application, and then
that application has the bound user's access to LDAP.

The message could be indicating a bug in the app - that it should
release its resources (such as descriptors) before exec().  Except, I
presume this happens in system() as well?  I'd be unfortunate if
LDAP apps could not use system() safely.

> +#ifdef _GNU_SOURCE
> +       fcntl(s, F_SETFD, FD_CLOEXEC);
> +#endif

_GNU_SOURCE depends on the compiler flags.  Please try
	#ifdef FD_CLOEXEC
instead.

Also I expect the same should be done in os-local.c:ldap_pvt_socket(),
which opens ldapi:// sockets.  Can you check if the same problem
occurs if you run
	slapd ... -h ldapi://
and a client which listens to that URL instead of ldap:// ?
ldapi:// creates a unix-domain socket file somehwere, typically
	/usr/local/var/run/ldapi
If you want to use some other filename you can use
	ldapi://<URL-escaped filename>/
e.g.
	ldapi://%2Fhome%2Fjsafrane%2Fldapi/

-- 
Hallvard