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):
libsetrans-0.1.7-1

How reproducible:
Always

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: