Bug 1260238 - RFE: restorecon should say in verbose mode when it doesn't change a context due to customizable_type
RFE: restorecon should say in verbose mode when it doesn't change a context d...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils (Show other bugs)
All Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Petr Lautrbach
Dalibor Pospíšil
: Documentation, FutureFeature, Reopened
Depends On:
  Show dependency treegraph
Reported: 2015-09-04 17:48 EDT by M. Scherer
Modified: 2018-04-10 12:37 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1513098 (view as bug list)
Last Closed: 2018-04-10 12:36:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0913 None None None 2018-04-10 12:37 EDT

  None (edit)
Description M. Scherer 2015-09-04 17:48:20 EDT
Description of problem:

So, this afternoon, I did played with selinux sandbox, and due to me experimenting, this resulted into this:
$ ls -ldZ /tmp/     
drwxrwxrwt. root root unconfined_u:object_r:sandbox_file_t:s0:c446,c554 /tmp/

(I found out later in the day when openvpn failed, and it was by using -T on /tmp, me likely not doing things correctly and running it as root, etc. Bug is not about how I did stupid things by being stupid).

So the easy solution to fix is restorecon:

$ sudo restorecon -v /tmp                                              
$ ls -ldZ /tmp/     
drwxrwxrwt. root root unconfined_u:object_r:sandbox_file_t:s0:c446,c554 /tmp/

Nope. I did checked with matchpathcon:

$ matchpathcon /tmp 
/tmp	system_u:object_r:tmp_t:s0

So let's fix by hand:

~ $ sudo chcon -v  system_u:object_r:tmp_t:s0 /tmp
changement du contexte de sécurité de « /tmp »

and now it worked.
Problem is "why restorecon silently said nothing ?"

Version-Release number of selected component (if applicable):

How reproducible:
Each time. Provided 

Steps to Reproduce:
1. chcon  unconfined_u:object_r:sandbox_file_t:s0:c446,c554  /tmp
2. restorecon -v /tmp
3. ls -lZd /tmp

Actual results:
the context is unconfined_u:object_r:sandbox_file_t:s0:c446,c554

Expected results:
the context is system_u:object_r:tmp_t:s0

Additional info:
I did tried on another platform, so maybe that's more than RHEL 7.2.
Comment 2 M. Scherer 2015-09-04 18:10:09 EDT
If that matter, /tmp is not a tmpfs. 

I did some tweak and it seems to be really just sandbox_file_t :
~ $ sudo chcon   system_u:object_r:sandbox_file_t:s0 /tmp  
~ $ sudo restorecon -v /tmp                                
~ $ sudo chcon system_u:object_r:etc_t:s0 /tmp/            
~ $ sudo restorecon -v /tmp                    
restorecon reset /tmp context system_u:object_r:etc_t:s0->system_u:object_r:tmp_t:s0

I did test with other directories, and /root, /etc exhibit the same behavior.
I also did test with others contexts, and so far, it work fine, except with sandbox_file_t.
Comment 3 M. Scherer 2015-09-04 20:19:53 EDT
So digging into the issue, that's because sandbox_file_t is listed in customizable_type. 

I am not sure on what would be a right fix, but I would expect at minima that restorecon -v  tell me that it doesn't restore on purpose the context.

But I agree that's a tricky problem to decide what is the right behavior :/
Comment 4 Milos Malik 2015-09-07 03:18:40 EDT
# ls -dZ /tmp/
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp/
# chcon -t sandbox_file_t /tmp
# ls -dZ /tmp/
drwxrwxrwt. root root system_u:object_r:sandbox_file_t:s0 /tmp/
# restorecon -RvF /tmp/
restorecon reset /tmp context system_u:object_r:sandbox_file_t:s0->system_u:object_r:tmp_t:s0
Comment 5 Daniel Walsh 2015-09-07 08:04:59 EDT
restorecon -F forces relabel, Ignores customizable types. But I would not advise this since things like containers, svirt, openshift, sandboxes all rely on this alternate label.
Comment 6 M. Scherer 2015-09-07 10:57:23 EDT
Well, that's because it is not advisable to use -F by default that I changed the title of this bug to be a RFE for "say something when something was not changed despites user expectation".

I do not see how and why the fact that svirt openshift and others use that as a reason to not give more information to users, therefor, I reopen the RFE.
Comment 7 Daniel Walsh 2015-09-09 10:42:38 EDT
Ok, I can see this.  Although it will potentially noisy on a full restore.
Comment 9 Petr Lautrbach 2016-07-19 15:20:07 EDT
You can use restorecon -vv if you need more verbose output:

# restorecon -vv /etc/machine-id
restorecon: /etc/machine-id not reset customized by admin to system_u:object_r:svirt_sandbox_file_t:s0
Comment 10 M. Scherer 2016-07-19 15:39:35 EDT
I didn't knew there was 2 different level of verbosity, likely because that's neither in the man page, nor the --help output.
Comment 19 errata-xmlrpc 2018-04-10 12:36:29 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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