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): coreutils-5.2.1-48 How reproducible: Always 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.
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.
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.
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 problems. Finally, wouldn't it be better to just put the log file in /var/log/postgresql?