Bug 159973 - chcon fails when context is specified via switches
chcon fails when context is specified via switches
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2005-06-09 16:23 EDT by Tom Lane
Modified: 2013-07-02 23:06 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-16 07:46:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2005-06-09 16:23:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; HP-UX B.10.20 9000/785)

Description of problem:
In FC4, chcon works when given the context as a:b:c, but not when given it as
-u a -r b -t c.  The latter works in FC3.

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

How reproducible:

Steps to Reproduce:
As root:
1. touch q
2. chcon -u system_u -r object_r -t postgresql_log_t q

Actual Results:  chcon: can't apply partial context to unlabeled file q

Expected Results:  Should work.  Does work if I say
chcon system_u:object_r:postgresql_log_t q

Additional info:

This syntax works fine in FC3 (coreutils-5.2.1-31).  It's rather a serious problem for me because the postgresql initscript is using the form with switches, which I (perhaps mistakenly) thought was the preferred way.
Comment 1 Tim Waugh 2005-06-16 07:39:14 EDT
Note: Test case must be run on a system with selinux disabled.

1. touch q
2. chcon -u system_u -r object_r -t postgresql_log_t q
3. chcon system_u:object_r:postgresql_log_t q

2 fails but is expected to succeed.
Comment 2 Tim Waugh 2005-06-16 07:46:29 EDT
Tom, chcon.c has not changed at all between FC3 and FC4 as far as I can tell.

I don't think that setting individual components like that is the best way; I
think that specifying the entire context as in step 3 is better.  The difference
is that step 2 acts as if there is an implicit --reference=q argument, whereas
step 3 builds a new context from scratch.
Comment 3 Russell Coker 2005-06-16 11:07:50 EDT
I agree with Tim.  The preferred manner is to specify identity:role:type.  
When we get MLS we will have categories and levels as well, you don't want to 
have a dozen parameters to deal with in your scripts.  Best to just take the 
security context as a blob of data and don't worry about parsing it. 
If you want to restore the context of a file in a startup script the correct 
thing to do is to call restorecon.  If you hard code contexts in scripts then 
someone who modifies their policy will have lots of pain.  If you use 
restorecon then as long as their .fc files match up then they have no 
Finally, wouldn't it be better to just put the log file 
in /var/log/postgresql? 

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