Ceph

this may explain part of the problem with #13000, I'll try to repeat that

@ken, do you know why the restart of the daemon is necessary when selinux is involved ? The initial addition of this behavior (which is perceived as a regression) was in https://github.com/ceph/ceph/pull/5421 ( https://github.com/ceph/ceph/commit/c6d6c783f46154186566d340f5f026fe78f5f961 specifically).

@Boris, could you please assign the issue back to me when you collected more information regarding the need for a restart ?

<loicd> branto: do you know why the restart of the daemon is necessary when selinux is involved ? 
<loicd> branto: I should have asked you first but only now found the original commit introducing this change ( https://github.com/ceph/ceph/commit/c6d6c783f46154186566d340f5f026fe78f5f961)
<sage> branto: what happens if you wait to restart (say, another day or two)?  does it break?
<sage> or does it just mean that you aren't protected during that interval?
<sage> e..g, what happens if you relabel, the daemon creates some new files, and is then restarted?  is that a race we have to worry about?
<branto> sage: I'm not completely sure, there might be some files that will be mislabelled afterward, I suppose I'd have to test that
<branto> it is a common practice to restart the daemons when installing the policy, though
<branto> even the fedora packaging guidelines suggest to do that
<branto> the patch that loicd linked got improved to (re)start the service iff it was running before
<loicd> branto: I noticed it got a lot better indeed :-)
<loicd> branto: it would help a great deal to have a strong rationale justifying the need to restart the daemons because it's going to be a significant and unexpected change for Ceph sysadmins. 
<ktdreyer> agreed loicd 
<ktdreyer> since selinux is shipping in a major release boundary, maybe it's ok to simply document "restart your daemons when upgrading to infernalis" or something?
<branto> I'll check tomorrow whether there will be any mislabelled files if we do not restart the services
<branto> but for starters, the SELinux policy will not be in effect until you restart the daemons

OK, some more info:

(18:40:09) branto: ktdreyer, sage, loicd: I thought about it a bit and I believe it really could make some mislabelled files, e.g. you have a mislabelled directory, restorecon will list the directory to know its contents, then you create a new file, that file will be incorrectly labelled and the restorecon call won't fix that, then you get the denials when the ceph daemons will try to access the file
(18:40:40) branto: s/then you create/then a daemon creates/
(18:42:19) branto: i.e.: we need to restart the daemons in order to avoid (racy) mislabelled files

@Ken: Unfortunately, there is no way to change a context of running process. I believe this behaviour is by design -- to avoid security problems if there ever was such a method.

@Boris: back to you. Although I don't have the knowledge to do the proposed change, I'll be available if you need a rubber duck :-)

<branto> loicd, sage: we could probably move the daemon stop/start inside the condition that checks whether the policy changed to minimize the impact, i.e.: restart the daemons only if the policy version changed
<sage> branto: yeah, let's do that

The PR https://github.com/ceph/ceph/pull/6142