On 22 September 2016 at 12:55, Ansis Atteka <aatt...@nicira.com> wrote:
> On Thu, Sep 22, 2016 at 3:54 AM, Joe Stringer <j...@ovn.org> wrote:
>> ovs-lib creates several directories directly from the script, but
>> doesn't make any attempt to ensure that the correct SELinux context is
>> applied to these directories. As a result, the created directories end
>> up with type var_run_t rather than openvswitch_var_run_t.
>> During reboot using a tmpfs for /var/run, startup scripts will invoke
>> ovs-lib to create these directories with the wrong context. If SELinux
>> is enabled, OVS will fail to start as it cannot write to this directory.
>> Fix the issue by sprinkling "restorecon" in each of the places where
>> directories are created. In practice, many of these should otherwise be
>> handled by packaging scripts but if they exist then we should ensure the
>> correct SELinux context is set.
>> On systems where 'restorecon' is unavailable, this should be a no-op.
>> VMware-BZ: #1732672
>> Signed-off-by: Joe Stringer <j...@ovn.org>
> Acked-by: Ansis Atteka <aatt...@ovn.org>
> I could give Tested-by, but only in 12 hours, if you are willing to wait.
I would appreciate that. I'd like to get this in v2.6, but I think we
have a little bit of time for that.
> One thing that caught my attention is that "restorecon -R /" may take
> really long time. I guess, none of the path variables expand to / or
> any other directory that has bunch of files by default in it, do they?
> Also, as an optimization - would it make sense to call "restorecon
> ..." only if "test -d ..." returned false?
I think this is reasonable. I sent a v2 to do this, and not use "-R".
If this script is creating the directory, then -R is unnecessary:
dev mailing list