Bug 978382

Summary:	User instance of restorecond is not started when logged in via ssh
Product:	Red Hat Enterprise Linux 6	Reporter:	Michal Trunecka <mtruneck>
Component:	policycoreutils	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.5	CC:	dwalsh, ebenes
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-06-28 13:10:09 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:
Embargoed:

Description Michal Trunecka 2013-06-26 13:55:12 UTC

Description of problem:
The user instance of restorecond (with -u argument) is not started when logging in via ssh. I didn't find any information about why it was separated from the restorecond (init.d) service and how is a user supposed to run it.

In Bug 636272, there is a note that it is started during gnome login, but it doesn't cover this issue.

I think it is not correct behaviour since files in home directory are created with wrong contexts without restorecond. In addition, it works on RHEL5 (and on RHEL7 it is mostly replaced by filename transitions).

Version-Release number of selected component (if applicable):
policycoreutils-2.0.83-19.30.el6.x86_64


Steps to Reproduce:
1.   ssh as ordinary user
2.   mkdir ~/public_html
3.   see the context of created dir.

Comment 1 Daniel Walsh 2013-06-27 20:11:01 UTC

You could run it in the user session via sshd but we decided not to turn it on by default. The problem is there is no session management cabability to prevent multiple ssh logins creating multip restorecond -u sessions.

Comment 2 Michal Trunecka 2013-06-28 09:25:58 UTC

So if I understand it correctly, the following part of man page is not true, when running by user himself or sshd:
"Uses dbus to make sure only one restorecond is running per user session."

The thing is that when users log in via ssh and create files and dirs in home directory, they'll get wrong contexts. This is not true for RHEL5 or RHEL7 and it can be confusing. And since the correct filesystem labeling is the precondition of correct selinux performance, it seems like an issue to me.

And what was the reason to split restorecond comparing the single restorecond in RHEL5?

Comment 3 Daniel Walsh 2013-06-28 11:35:14 UTC

ssh sessions do not start a user dbus session,so

"Uses dbus to make sure only one restorecond is running per user session."

Does not apply.

RHEL5 is the same, except we did very little labeling in the users homedir.

Other then ~/.ssh what directories are you worried about?  I guess public_html.

Comment 4 Michal Trunecka 2013-06-28 12:26:32 UTC

Yes, public_html, but I was mainly concerned about "~/*". I thought that it is necessary to assign correct context instead of inheriting user_home_dir_t.

Comment 5 Daniel Walsh 2013-06-28 13:05:25 UTC

No,  Files will be created with the default label of user_home_t.  We have a transition rule that says a user domain(unconfined_t) will create content in a directory labeled user_home_dir_t as user_home_t.

There are only a couple of directories/files which could get mislabeled, without restorecond -u running, and for the most part these never effect the normal user.

Comment 6 Michal Trunecka 2013-06-28 13:08:09 UTC

Ok. If so, I agree to close as wontfix.

Comment 7 Daniel Walsh 2013-06-28 13:10:09 UTC

Unfortunately...