Bug 1007553 - user_wine_t and staff_wine_t don't handle wine_home_t
Summary: user_wine_t and staff_wine_t don't handle wine_home_t
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-12 18:22 UTC by Alphonse Steiner
Modified: 2013-09-25 19:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-25 19:04:02 UTC
Type: Bug


Attachments (Terms of Use)

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.


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