Red Hat Bugzilla – Bug 137068
targeted permissive policy forces ext_attr on ext3; corrupts multiboot
Last modified: 2007-11-30 17:10:53 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041012 Epiphany/1.4.4 Description of problem: Using targeted permissive SELinux policy automatically adds the ext_attr feature to any mounted writeable ext3 filesystem without warning. This corrupts ext3 filesystems used by any Redhat 9 (or prior) kernel. Subsequent attempts to boot RH9 with a root that was mounted writeable and written under targeted permissive policy, will fail with a kernel console message such as attempt to access beyond end of device 0309: rw=0, want=1219858868, limit=5863693 because the old kernel does not interpret ext_attr the same way that FC3test3 does. The impact of this exacerbated in FCtest3 because hald and fstab-sync automatically find mount all ext3 filesystems (using mount points such as /media/idediskN), even those that were omitted from the explicit DiskDruid mount list during installation of FC3test3. Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.31-1 How reproducible: Always Steps to Reproduce: 1. Use RH9 rescue mode to create a new ext3 filesystem: fdisk, then "mke2fs -j <devicepath>". Use "tune2fs -l <device path>" to see that the filesystem attributes are exactly "has_journal filetype sparse-super" and do not include ext_attr. 2. Boot FC3test3 with SELinux in targeted permissive mode, and create a new file in the new filesystem (typically available as /media/idediskN, which was discovered and mounted by hald and fstab-sync.) 3. Run "tune2fs -l <devicepath>" and notice that ext_attr has been added to the filesystem attributes. Actual Results: ext_attr has been added to the attributes of the new filesystem. This will be true for any mounted writeable ext3 filesystem that actually gets written. Expected Results: targeted permissive mode should not destroy the usability of ext3 filesystems by RH9 kernels. The system should require explicit confirmation before adding ext_attr attribute to any ext3 filesystem that does not already have it. Additional info: Entering as high severity because filesystem is "corrupted" by new ext_attr attribute: it cannot be used any more by multi-booted RH9 or below.
I don't understand how this is a policy bug. Are you sure it's not say because you simply accessed the file, and the atime was updated on a file, which caused ext3 to add ext_attr? What specifically makes you think it's policy? If you do this same procedure except boot with selinux=0, you do not see the issue?
I just tried it. No, I do not see the issue. So it looks to ome like policy is what adds ext_attr "unexpectedly". In response to Additional Comment #1, I did: FC3test3: remove /dev/hda13 from /etc/fstab [hda13 is last filesystem on drive] RH9 rescue mode: mke2fs -j /dev/hda13 FC3test3 with selinux=0: /dev/hda13 gets found and mounted; /etc/fstab says "/dev/hda13 /media/idedisk2 ext3 pamconsole,exec,noauto,managed 0 0" Initial "tune2fs -l /dev/hda13" shows "has_journal filetype needs_recovery sparse_super" [as when this bug was first entered]; note that ext_attr is not present. Create a file there by "cd /media/idedisk2; date >foo; sync". Second "tune2fs -l /dev/hda13" does not show ext_attr. This is different from original entry of this bug. At original entry, the second "tune2fs -l /dev/hda13" did show ext_attr had been added. So, booting with selinux=0 does not add ext_attr automatically, whereas booting with targeted permissive mode _does_ add ext_attr.
As noted in bug 137072 HAL will no longer add entries to the /etc/fstab file for non-hotpluggable drives without removable media. This should limit the impact of this bug for people with multiboot systems. It will still apply for e.g. filesystems stemming from disks in USB or Firewire enclosures.
This issue is a side-effect of extended attributes combined with symlinks. On old systems there are essentially no cases where you end up applying an xattr to a symlink. On SELinux, though, that happens all the time. The problem is that the old 2.4 code used to detect whether a symlink was "fast" or "slow" (ie. whether the symlink data was embedded in the inode block) by looking at the i_blocks count of the inode. However, with an xattr on the inode, the i_blocks will be raised so the old kernel thinks it's a slow symlink even if it's a fast one. That was an unanticipated side-effect of xattrs that is unfortunately now hard-coded into the standard xattr behaviour for ext3. Newer 2.4 kernels have their symlink test corrected to take into account the presence of xattrs even if you have not actually compiled xattr support into the kernel. So this is fixed upstream in newer 2.4 kernels (and in both RHEL3 and FC1.) The patch is at http://lkml.org/lkml/2004/1/1/146 if you want this for other 2.4 kernels.