I can verify that rebuilding openswan with the following patch:

--- programs/pluto/plutomain.c.old  2013-12-12 15:06:52.182664449 -0600
+++ programs/pluto/plutomain.c  2013-12-12 15:08:01.229676601 -0600
@@ -359,7 +359,7 @@
    capng_clear(CAPNG_SELECT_BOTH);
    capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
            CAP_NET_BIND_SERVICE, CAP_NET_ADMIN, CAP_NET_RAW,
-           CAP_IPC_LOCK, -1);
+           CAP_IPC_LOCK, CAP_DAC_OVERRIDE, -1);
    /* our children must be able to CAP_NET_ADMIN to change routes.
     */
    capng_updatev(CAPNG_ADD, CAPNG_BOUNDING_SET,

does fix the problem for neutron-vpn-agent using openswan.

Terry, can you try using groups and giving it a group write? We are strongly encouraged not to remove CAP_DAC_OVERRIDE. That is, put root in the neutron group and make directory g+w

We can hack around it, but that's what it'll be: a hack. Since the directories are created at runtime each time a particular vpn service object is created, it would mean editing the code in neutron to just assume that root happens to be in the neutron group or editing the code to do setfacl every time a directory is created, etc. It certainly doesn't seem like the type of patch that they'd accept upstream.

It seems like if one is 1) running a service as root and 2) passing in a directory that needs to be written to owned by 'not root', the admin intention is pretty clear. Just my $0.02, of course. Any chance of detecting that particular case and only enabling CAP_DAC_OVERRIDE then? Or even just enabling it just long enough to create the necessary directories/files, then disabling again?

Created attachment 878708 [details]
Keep CAP_DAC_OVERRIDE only when necessary

This patch, instead of unconditionally keeping CAP_DAC_OVERRIDE, instead checks the parent directory of ctlbase for RWX owner/gid perms if running as root and keeps CAP_DAC_OVERRIDE if root is passing in a ctlbase that it wouldn't be able to access after dropping the capability. In this way, only when it is absolutely necessary and obviously the intention of the user running pluto is this capability retained.

As a note, in most normal circumstances I'd never check permissions then try an operation, but as you can't restore capabilities that you've given up and you would need the capability removed to be able to test via creation, I go ahead and do the check. Also, I would have used euidaccess() instead of manually checking the uid/gid permissions, but access/euidaccess code in to return 0 if uid/euid == 0.

Created attachment 878844 [details]
patch to move CAP_DAC_OVERRIDE drop after we create the socket

Can you try the attached patch - It works for me, although due to the missing permissions during shutdown, you will have to remove the parent directory so the pid file and socket get cleaned up properly, as we have lost the capability to clean those up if the parent dir is non-root

The attached patch didn't quite work, but pwouters did another build moving the privilege drop even later that seems to work: https://brewweb.devel.redhat.com/taskinfo?taskID=7275538.

With the patch, pluto now starts without error. When deleting the ipsec site connection via neutron, the /var/lib/neutron/ipsec/${id} directory is successfully deleted as well.

yes: https://bugzilla.redhat.com/show_bug.cgi?id=1092047

shouldn't this bug be closed by now?

It will be closed by the rhel-6.6 release

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1588.html