Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 623920

Summary: Define a selinux policy for test harness
Product: [Retired] Beaker Reporter: Marian Csontos <mcsontos>
Component: beahAssignee: Marian Csontos <mcsontos>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 0.5CC: azelinka, bpeck, dcallagh, kbaker, mcsontos, rmancy
Target Milestone: future_maint   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-11 13:48:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 669665    
Bug Blocks: 633239    

Description Marian Csontos 2010-08-13 06:58:21 UTC 
The task should run under configurable context (unconfined_t a default) instead of initrc_t.

Taking following from Bug 620969#c1:

The big difference in running 'make run' on command line and from the job is
that in command line it runs as

  unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

while when running under rhts/beaker as

  system_u:system_r:initrc_t:s0

The question is which one is correct?

I am in favor of unconfined_t:

- the shell and utilities should behave as on command line, should not they?
- for services (e.g. httpd) context transitions should be handled by policy

Actually this would be a configuration option with
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 as default.

See also following comments.
Comment 1 Ales Zelinka 2011-03-11 11:08:54 UTC 
ping, Any plans to implement this? Since RHTS times the dreaded initrc_t has caused many jobs to fail and time to be wasted...
Comment 2 Marian Csontos 2011-03-11 13:21:37 UTC 
FYI tasks run in unconfined_t context for some week now.
Comment 3 Ales Zelinka 2011-03-11 13:46:05 UTC 
good news, can we close this bug then?