Bug 426359 - After update to selinux-policy-targeted-3.0.8-68.fc8 all home directory files given unconfined policy
After update to selinux-policy-targeted-3.0.8-68.fc8 all home directory files...
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-12-20 09:22 EST by Need Real Name
Modified: 2008-01-16 15:59 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-16 15:59:23 EST
Type: ---
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 Need Real Name 2007-12-20 09:22:00 EST
Description of problem:
Just yum updated to version 3.0.8-68.fc8.
Running "fixfiles check /home" I noticed that all files in the home directory
now have a target policy of "unconfined_u:object_r:unconfined_xxxx_t" where xxxx
is from whatever the original policy was.
Comment 1 Daniel Walsh 2007-12-21 02:57:30 EST
Yes homedirs for uncofined users in Fedora 8 now default to unconfined_home_t
and friends.  user_home_t will still work.

In Fedora 9 we are removing the distinction on homedirs.  So all homedirs will
be labeled user_****_t.

In Fedora 8 guest is guest_****t, unconfined_t is uncofined_****_t etc.

We did not force a relabel so unconfined_t will work fine with a user_home_t or
an unconfined_home_t.
Comment 2 Need Real Name 2007-12-21 03:19:55 EST
I'm not sure I understand.
Did this change just occur during the last policy update?

Because with selinux-policy-targeted-3.0.8-64.fc8
> matchpathcon ~
/home/me  system_u:object_r:user_home_dir_t:s0
while with selinux-policy-targeted-3.0.8-68.fc8
> matchpathcon ~
/home/me  unconfined_u:object_r:unconfined_home_dir_t:s0

I guess if the change has truly no impact then it doesn't matter that much but
still it seems like a pretty significant change to occur between minor policy
releases particularly since it affects just about every file in /home.

Is there anywhere this change is documented (along with the implications of the

Comment 3 Need Real Name 2007-12-21 03:32:29 EST
Also, I'm not sure what you mean by **** is that a synonym for unconfined or is
it a new policy name/convention.

Also, in the latest policy, even files in ~/.ssh would be relabeled from
user_u:object_r:user_home_ssh_t to unconfined_u:object_r:unconfined_home_t

while interestingly files in ~/.mozilla get reballed from
usr_u:object_r:user_mozilla_home_t to 

So, I'm not sure that I understand what is going on and what is the rationale
for why some things get relabeled to unconfined_home_t while others get
relabelled to unconfined_xxxxx_home_t. Particularly, since I would think that
.ssh would be more security sensitive then .mozilla.

If this truly is the intended change, can you point me to some documentation and
explanation of what the changes mean and why.

Comment 4 Daniel Walsh 2007-12-22 08:11:29 EST
No I ment the **** to indicate multiple labels in the homedir.


The default SELinux login user on a fresh install was unconfined_u.   But on
upgrades it was system_u.  So in the 68 update I fixed this since the system_u
login user was not working correctly in all cases.  So this was actually a
bugfix.  The actual type for system_u and unconfined_u was still unconfined_t so
most users would not see the change.

The difference in homedirs is also caused by upgrade versus fresh install.
We wanted to change the default types but did not want to force everyone to relabel.

The change should have little impact other then fixing some bugs when restarting
Comment 5 Need Real Name 2007-12-22 23:07:40 EST
OK. So I now understand that you are making the following changes in home
user_u            ->unconfined_u
user_****_home_t  ->unconfined_****_home_t

But why are you changing:
[~/.ssh] user_home_ssh_t -> unconfined_home_t
[~/.spamassassin and ~/.razor] user_spamassassin_home_t -> unconfined_home_t
[~/.mplayer] user_mplayer_home_t -> unconfined_home_t
[~/.pyzor] user_pyzor_home_t -> unconfined_home_t
[~/.screenrc] usr_screen_ro_home_t -> unconfined_home_t
[~/.ICEauthority] user_iceauth_home_t -> unconfined_home_t

While other special directories keep their special context such as:
unconfined_gnome_home_t, unconfined_mozilla_home_t.

Are these "special" context distinctions no longer important or is this a mistake?
Again, it would be helpful if you could point me (and others) to documentation
of such changes...

Please explain this inconsistency in relabeling...

Comment 6 Mark Knoop 2007-12-23 12:19:41 EST
This does seem to have broken mail delivery (postfix/procmail) for me.
audit2allow recommends:

#============= postfix_local_t ==============
allow postfix_local_t unconfined_home_dir_t:dir search;
allow postfix_local_t unconfined_home_t:file { read getattr };

The access is denied and the mail is bounced. This seems like a bug to me.
Comment 7 Daniel Walsh 2007-12-31 10:10:06 EST
What directory/file is postfix_locat trying to read?  I don't believe this was
allowed prior to the change?
Comment 8 Need Real Name 2007-12-31 10:47:32 EST
Can you just confirm for me that it was intentional to remove the special
contect labeling for:
(along with probably some others that I don't use) from

from /etc/selinux/contexts
Comment 9 Daniel Walsh 2008-01-03 11:20:45 EST
Everyhthing but spamassassin should probably be changed.
Comment 10 Need Real Name 2008-01-04 11:30:09 EST
OK - so does that mean that in subsequent policy releases the .spamassassin
labeling will be changed to unconfined_spamassassin_home_t analogous to the
original user_spamassassin_home_t labeling?
Comment 11 Daniel Walsh 2008-01-04 14:17:55 EST
I am not sure.  This is much more clean in Rawhide, but I have to find a
compromise in F8.  I do not want unconfined processes running confined
spamassassin and spamc apps.  So policy is somewhat difficult to write to allow
selected directory access to a unconfined home dir.

What was postfix_local trying to access that caused the AVC?
Comment 12 Need Real Name 2008-01-15 14:54:28 EST
Dan, it seems that the person who reported the postfix_local is not on the bug c
list so he may not be reading this thread.

As the original reporter, I am not having any problems per-se but just
originally started this thread because I noticed these changes to the default
home directory labeling and wasn't sure why or even whether the changes were

I now understand that you indeed intentionally were eliminating some of the
special labeling in the home directory and I personally am fine with that so far
since I haven't seen any ill effects from it. Also, I look forward to F9 to see
it all more logically cleaned up :)


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