A new top-level directory was created, gaining the default label for new top-level directories, default_t.

SELinux denies starting a service if ExecStart is a program created in a new top-level directory (/ansible-managed/).

Is there a purpose to this denial?

sealert suggested that any of the following labels would have been permitted:

  • bin_t
  • boot_t
  • etc_runtime_t
  • etc_t
  • initrc_state_t
  • ld_so_t
  • lib_t
  • src_t
  • system_con
  • system_db_t
  • textrel_shlib_t
  • tmpfs_t
  • usr_t
  • var_run_t

so we can rule out the possibility that it blocks someone running a daemon from a user-writeable location like /dev/shm (tmpfs_t).

SELinux policy: selinux-policy-targeted-3.13.1-225.18.fc25.noarch


The SELinux policy exists to define policies of what is allowed in the system. When you create some different files with generic labels, the policy is quite permissive, but prevents some of potential threats.

The only threat is not running something from /dev/shm, but running something from potentially user-writable directories can be very dangerous (especially in case the daemon runs as a root, isn't it?).

Generally, all the new services/daemons in Fedora are required to have some SELinux policy so they the SELinux has at least some control of them. I would recommend you doing so, if it is some long-living service.

If it should be ad-hoc service, just assign to it some generic bin_t label , which should do that. Or install the binaries into /opt/your-path/(s)bin/ and possibly adjust the policy to get the labels correctly in your directory tree.

  • I don't understand that sentence "the only threat is not ... " :). Are you saying allowing the user-writeable /dev/shm is a bug, that should be reported? I'd be very happy to do so if you can confirm.
    – sourcejedi
    Jul 13 '17 at 17:16
  • In your question, you used tmpfs_t as an example what would be allowed (according to the setroubleshoot -- it does not have to be allowed eventually). It has probably a reason why it is there, but it would require some broader investigation of the policy. The meaning of that sentence was that there are other locations and other labels that are clearly not allowed.
    – Jakuje
    Jul 14 '17 at 8:18
  • I am resisting the temptation to downvote this again, on the sole grounds that it made me investigate more fully :). As you say in your comment, there were more details, so I've written an answer to my question. I took care to ask my specific question in both the title and in the body (the only sentence ending in '?'). I was already aware of bin_t, but had not yet decided on exactly what alternative solution I wanted to use. My script is actually labelled etc_t now. The setup is intended to be portable, so it's simplest to appease SELinux by using an appropriate existing directory.
    – sourcejedi
    Jul 14 '17 at 11:31
  • Good to see you have moved along with the investigation. You asked a question "why it is denied" and the answer is "because it is not allowed". This is how the policy works. But I tried to be more verbose in my answer to point out to the solution. You answer is only retracting some of the wrong assumptions of the question and should have been rather comment/edit to the question. If you wish to have the setup portable, using existing directories is better idea.
    – Jakuje
    Jul 14 '17 at 12:08

so we can rule out the possibility that it blocks someone running a daemon from a user-writeable location like /dev/shm (tmpfs_t).


/dev/shm/ is labelled tmpfs_t, but when a user creates a file in /dev/shm/ it is labelled as user_tmp_t.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.