Bug 1007553

Summary: user_wine_t and staff_wine_t don't handle wine_home_t
Product: [Fedora] Fedora Reporter: Alphonse Steiner <alphsteiner>
Component: selinux-policy-targetedAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-25 19:04:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alphonse Steiner 2013-09-12 18:22:08 UTC
When a seuser user_u starts wine, the application is run with the context user_wine_t, but this context does not handle wine_home_t, which is the label of the wine home directory. Using the tool sesearch, we can see that the rules are defined for wine_t.

I have used the command in permissive mode to get all the denials. Here a summary:

First problem: when wine is started for the first time, it creates its home directory .wine, but with the wrong label user_home_dir_t. Restorecon fixes this label and set it to wine_home_t.

Second problem: wine cannot access its configuration directory. Audit2allow reports:

allow user_wine_t data_home_t:file { write create unlink };
allow user_wine_t wine_home_t:dir { write remove_name add_name };
allow user_wine_t wine_home_t:file { write rename create unlink setattr };
allow user_wine_t wine_home_t:lnk_file read;

The data_home_t is for the .desktop files and icons in .local/share.

The same problems exist for seuser staff_u.

Comment 1 Daniel Walsh 2013-09-23 18:05:51 UTC
28d07eee671b8c4d79b46adba5e426b4cd905c82 fixes this in git.