Bug 1339135

I think the behavior needs to be compatible with 'mkdir -p', which does not set the file context of directories by default, but only if the -Z option is used.

I would propose a patch upstream to make install(1) set file context of directories if the -Z option is used.  Does that work for you?

install with and without -Z behaves alike for regular files. Both call setdefaultfilecon (char const *file) at last. The difference is only when --context=CTX is used. It seems to be different from behavior of 'cp'.

While I don't know if it's correct to compare 'cp' with 'install' analogous to 'install -d' and mkdir, I think that it would be great if install -d/-D is more SELinux aware than 'mkdir' and sets default contexts automagically even when there's no -Z option used.

(In reply to Petr Lautrbach from comment #2)
> install with and without -Z behaves alike for regular files. Both call
> setdefaultfilecon (char const *file) at last.

Not really.  setdefaultfilecon() is called only if the -Z option is _not_ used, and only for the target file.  If -Z is used, setdefaultfilecon() is disabled and restorecon() is used instead.  There is a comment in src/install.c saying that setdefaultfilecon() can be removed in a future version of coreutils:

    case 'Z':
      if (selinux_enabled)
        {
          /* Disable use of the install(1) specific setdefaultfilecon().
             Note setdefaultfilecon() is different from the newer and more
             generic restorecon() in that the former sets the context of
             the dest files to that returned by matchpathcon directly,
             thus discarding MLS level and user identity of the file.
             TODO: consider removing setdefaultfilecon() in future.  */
          use_default_selinux_context = false;

> The difference is only when
> --context=CTX is used. It seems to be different from behavior of 'cp'.

I believe that long term goal of coreutils upstream is to unify handling the -Z and --context options in all of these utilities:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=7958a4a4

> While I don't know if it's correct to compare 'cp' with 'install' analogous
> to 'install -d' and mkdir, I think that it would be great if install -d/-D
> is more SELinux aware than 'mkdir' and sets default contexts automagically
> even when there's no -Z option used.

What is the motivation behind this request?

Why would it be a problem to explicitly request SELinux context initialization by the -Z option of install?

-Z option would be a great step forward.

The motivation of this bug is to have correct labels on new created entities in a filesystem. 

As it is now, install creates a directory and the new directory inherits a label from its parent even when there's defined another label in the policy. It means that the new directory structure can have wrong labels. Only a file in relabeled either by setdefaultfilecon() or restorecon().

So it would be great if install could set labels to all new directory created by it as it does for files.

The expected result of the scenario from description would be:

$ sudo semanage fcontext -a -t user_home_t "/tmp/foobar(/.*)?"
$ install -D foo /tmp/foobar/foo
$ ls -Zd /tmp/foobar
unconfined_u:object_r:user_home_t:s0 /tmp/foobar
$ ls -Z /tmp/foobar/foo
system_u:object_r:user_home_t:s0 /tmp/foobar/foo
$ rm -rf /tmp/foobar
$ install -d /tmp/foobar
$ ls -Zd /tmp/foobar
unconfined_u:object_r:user_home_t:s0 /tmp/foobar

(In reply to Petr Lautrbach from comment #4)
> -Z option would be a great step forward.

Thanks for clarification!

Let's start with making -Z work also for directories.  Then I will ask upstream what they mean by removing setdefaultfilecon() in future.  It can mean either not to set default context unless -Z is given, or to replace it by restorecon(), which would make -Z a no-op as I understand it.

(In reply to Kamil Dudka from comment #5)
> Let's start with making -Z work also for directories.

proposed upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23868

Incorporated upstream's suggestions on the patch:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23868#11

upstream commit:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;h=v8.25-44-g502518b

fixed in coreutils-8.25-12.fc25

coreutils-8.25-7.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-75adc7da4f

coreutils-8.25-7.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-75adc7da4f

coreutils-8.25-7.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.