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)
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
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):
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
The patch is at
if you want this for other 2.4 kernels.