Bug 137068
Summary: | targeted permissive policy forces ext_attr on ext3; corrupts multiboot | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> |
Component: | kernel | Assignee: | Stephen Tweedie <sct> |
Status: | CLOSED UPSTREAM | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | davidz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-27 12:53:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
John Reiser
2004-10-25 17:17:27 UTC
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. |