Bug 1339135 - install -d or install -D is not setting the context on directories
Summary: install -d or install -D is not setting the context on directories
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Patch, Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-24 08:43 UTC by Petr Lautrbach
Modified: 2016-11-03 23:55 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-11-03 23:55:02 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 767318 None None None Never
Red Hat Bugzilla 801522 None None None Never

Internal Trackers: 767318 801522

Description Petr Lautrbach 2016-05-24 08:43:01 UTC
Description of problem:

install -d or install -D is not setting the context on directories to match file_contexts, only on the final file.

Test case:

$ sudo semanage fcontext -a -t user_home_t "/tmp/foobar(/.*)?"
$ touch foo
$ install -D foo /tmp/foobar/foo
$ ls -Zd /tmp/foobar
unconfined_u:object_r:user_tmp_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_tmp_t:s0 /tmp/foobar
$ restorecon -v /tmp/foobar
restorecon reset /tmp/foobar context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:user_home_t:s0

Comment 1 Kamil Dudka 2016-06-01 13:21:51 UTC
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?

Comment 2 Petr Lautrbach 2016-06-08 15:15:36 UTC
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.

Comment 3 Kamil Dudka 2016-06-09 10:54:31 UTC
(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?

Comment 4 Petr Lautrbach 2016-06-27 16:13:49 UTC
-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

Comment 5 Kamil Dudka 2016-06-29 12:30:12 UTC
(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.

Comment 6 Kamil Dudka 2016-06-29 12:58:42 UTC
(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

Comment 7 Kamil Dudka 2016-07-08 17:11:23 UTC
Incorporated upstream's suggestions on the patch:

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

Comment 8 Kamil Dudka 2016-07-08 20:53:05 UTC
upstream commit:

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

Comment 9 Kamil Dudka 2016-07-11 15:35:01 UTC
fixed in coreutils-8.25-12.fc25

Comment 10 Fedora Update System 2016-10-31 17:46:08 UTC
coreutils-8.25-7.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-75adc7da4f

Comment 11 Fedora Update System 2016-11-01 18:22:47 UTC
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

Comment 12 Fedora Update System 2016-11-03 23:55:02 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.