Description of problem: The FC4 kernel doesn't understand the MLS suffix in the context of on-disk inodes which have been created in FC5. This results in errors like: Apr 1 10:30:24 random kernel: inode_doinit_with_dentry: context_to_sid(user_u:object_r:user_home_t:s0) returned 22 for dev=dm-1 ino=352500 for files in the /home directory that I want to share between FC4 and FC5. To get FC4 to work I have to boot with enforcing=0. I think the RHEL4 kernel has the same problem. Version-Release number of selected component (if applicable): 2.6.16-1.2069_FC4 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I thought that this was resolved in bug 174618 and upstream in 2.6.15. But the reporter indicates that it is still causing problems. Bug 177349 tracks the RHEL4 fix.
(In reply to comment #1) > I thought that this was resolved in bug 174618 and upstream in 2.6.15. > But the reporter indicates that it is still causing problems. > Bug 177349 tracks the RHEL4 fix. Oops, the latter should be bug 177439.
Created attachment 127429 [details] Fix MLS compatibility patch in 2.6.16 It looks as though it's an off-by-one issue. In mls_context_to_sid in mls.c the parsing code is returning *scontext pointing to one beyond the terminating null in the string. The compatibility code needs to add one more to *scontext to allow for this. With this patch added to the 2.6.16-1.2069_FC4 kernel I'm able to boot my FC4 installation in enforcing mode and access files in my shared /home. The context_to_sid warnings have all gone.
Attachment 127429 [details] is correct (to the extent that the mls parsing code and length check is correct, which can be debated, but that is another matter). Acked-by: Stephen Smalley <sds.gov>