Bug 169984 - mcs's :s0 isn't entirely transparent
Summary: mcs's :s0 isn't entirely transparent
Alias: None
Product: Fedora
Classification: Fedora
Component: libsetrans
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-06 04:14 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2005-12-10 18:03:14 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2005-10-06 04:14:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b4) Gecko/20050915 Fedora/1.5-0.5.0.beta1 Firefox/1.4

Description of problem:
One of the stated goals of libsetrans/mcs was to enabling a system that did not use mcs to continue working after enabling mcs, without relabeling.

It fails in at least two ways:

- prelink, and any other application that attempts to preserve the context of a file in a newly-created file intended to replace the original, gets an error from setxattr when it passes it what it got from getxattr, if the original context did not have a :s[0-9]* suffix.

- if you share a filesystem between say FC4, that does not have MCS at all, and FC devel, that has it enabled by default, directories created while FC devel is running cannot be accessed after booting into FC4

A simple (?) way to overcome this is to use an on-disk representation for :s0 that does not end in that suffix, having it stripped off on setxattr and introduced transparently on getxattr, if mcs is enabled.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Have an FC devel-tracking box installed before mcs went into the tree
2.Run prelink
3.Create a directory in a local filesystem shared with an FC4 install
4.Reboot into FC4

Actual Results:  2. will trigger several error messages in /var/log/prelink.log about failure to set contexts in new binaries, and will often result in a prelink crash.  fixfiles -F relabel will not fix the problem, although restorecon -F will.

After 4., the directory will be inaccessible

Expected Results:  If relabeling is to not be necessary, :s0 should probably be dropped from the on-disk representation.  prelink shouldn't crash, but that's a separate bug.

Additional info:

Comment 1 Daniel Walsh 2005-12-10 18:03:14 UTC
Fixed in Rawhide.

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