Bug 169984 - mcs's :s0 isn't entirely transparent
mcs's :s0 isn't entirely transparent
Product: Fedora
Classification: Fedora
Component: libsetrans (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-10-06 00:14 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-10 13:03:14 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 Alexandre Oliva 2005-10-06 00:14:04 EDT
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 13:03:14 EST
Fixed in Rawhide.

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