Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159973 - chcon fails when context is specified via switches
Summary: chcon fails when context is specified via switches
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-09 20:23 UTC by Tom Lane
Modified: 2013-07-03 03:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-16 11:46:29 UTC

Attachments (Terms of Use)

Description Tom Lane 2005-06-09 20:23:27 UTC
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 11:39:14 UTC
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 11:46:29 UTC
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 15:07:50 UTC
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.