Bug 978382 - User instance of restorecond is not started when logged in via ssh
User instance of restorecond is not started when logged in via ssh
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: policycoreutils (Show other bugs)
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2013-06-26 09:55 EDT by Michal Trunecka
Modified: 2014-09-30 19:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-06-28 09:10:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Trunecka 2013-06-26 09:55:12 EDT
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):

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 16:11:01 EDT
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 05:25:58 EDT
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 07:35:14 EDT
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 08:26:32 EDT
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 09:05:25 EDT
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 09:08:09 EDT
Ok. If so, I agree to close as wontfix.
Comment 7 Daniel Walsh 2013-06-28 09:10:09 EDT

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