Description of problem: When run from the F7test3 LiveCD, grub-install causes several of the following SELinux errors to pop up on the new notifier: Summary SELinux is preventing the /sbin/grub from using potentially mislabeled files (/tmp/sh-thd-1175367330 (deleted)). Detailed Description SELinux has denied /sbin/grub access to potentially mislabeled file(s) (/tmp /sh-thd-1175367330 (deleted)). This means that SELinux will not allow /sbin/grub to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access If you want /sbin/grub to access this files, you need to relabel them using restorecon -v /tmp/sh-thd-1175367330 (deleted). You might want to relabel the entire directory using restorecon -R -v /tmp. Additional Information Source Context user_u:system_r:bootloader_t Target Context user_u:object_r:tmp_t Target Objects /tmp/sh-thd-1175367330 (deleted) [ file ] Affected RPM Packages grub-0.97-13 [application] Policy RPM selinux-policy-2.5.10-2.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.home_tmp_bad_labels Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.20-1.3023.fc7 #1 SMP Sun Mar 25 22:12:02 EDT 2007 i686 athlon Alert Count 1 First Seen Sat 31 Mar 2007 08:15:14 PM EDT Last Seen Sat 31 Mar 2007 08:15:14 PM EDT Local ID cb145cc9-d84a-4900-9f36-71be93a6750f Line Numbers Raw Audit Messages avc: denied { write } for comm="grub" dev=dm-0 egid=0 euid=0 exe="/sbin/grub" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="grub-install.log.ew4019" path=2F746D702F73682D7468642D31313735333637333330202864656C6574656429 pid=4021 scontext=user_u:system_r:bootloader_t:s0 sgid=0 subj=user_u:system_r:bootloader_t:s0 suid=0 tclass=file tcontext=user_u:object_r:tmp_t:s0 tty=pts0 uid=0 Version-Release number of selected component (if applicable): F7test3 LiveCD How reproducible: Always Steps to Reproduce: 1. login as root on a terminal using su - 2. run grub-install with a target drive Actual results: A number of SELinux errors are listed in the notifier and grub-install is not successfully executed. Expected results: grub-install should not produce SELinux errors Additional info: Running grub manually and running commands from the grub prompt from the F7test3 LiveCD does not pop up SELinux errors.
This should hopefully be fixed with the next live CD. I'm hoping to get a pre-test version up in the next day or so.
I have the luxury of having a set of disks to test this on that is not my live drive so if you post a link here to the new LiveCD build, I can give it a spin along with checking on my other LiveCD installer problems (Bug 234719 and Bug 234724) and close them if they were just a symptom of this bug.
Finally got something up at http://torrent.fedoraproject.org/torrents/rawhide-20070411-i386-live.torrent If you could confirm that this and the other two bugs are fixed with it, that would be great.
Thanks for putting up a pre-release. You are almost there but no quite. Instead of several SELinux notifications, there is only one now when doing the following from the Rawhide 20070411.2 LiveCD: [root@localhost ~]# dmraid -s *** Set name : sil_ahaebidfbcbc size : 625140400 stride : 0 type : mirror status : ok subsets: 0 devs : 2 spares : 0 [root@localhost ~]# dmraid -ay [root@localhost ~]# dmraid -s *** Active Set name : sil_ahaebidfbcbc size : 625140400 stride : 0 type : mirror status : ok subsets: 0 devs : 2 spares : 0 [root@localhost ~]# grub-install /dev/mapper/ control live-rw sil_ahaebidfbcbc sil_ahaebidfbcbc1 sil_ahaebidfbcbc2 sil_ahaebidfbcbc3 [root@localhost ~]# grub-install /dev/mapper/sil_ahaebidfbcbc Probing devices to guess BIOS drives. This may take a long time. Unknown partition table signature /dev/mapper/sil_ahaebidfbcbc does not have any corresponding BIOS drive. [root@localhost ~]# At this point a single Denial message pops up (before it was multiple messages): Summary SELinux is preventing the /sbin/grub from using potentially mislabeled files (/tmp/grub-install.log.UW4296). Detailed Description SELinux has denied /sbin/grub access to potentially mislabeled file(s) (/tmp /grub-install.log.UW4296). This means that SELinux will not allow /sbin/grub to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access If you want /sbin/grub to access this files, you need to relabel them using restorecon -v /tmp/grub-install.log.UW4296. You might want to relabel the entire directory using restorecon -R -v /tmp. Additional Information Source Context user_u:system_r:bootloader_t Target Context user_u:object_r:tmp_t Target Objects /tmp/grub-install.log.UW4296 [ file ] Affected RPM Packages grub-0.97-13 [application] Policy RPM selinux-policy-2.5.11-8.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.home_tmp_bad_labels Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.20-1.3056.fc7 #1 SMP Tue Apr 10 14:44:53 EDT 2007 i686 athlon Alert Count 1 First Seen Fri 13 Apr 2007 12:05:44 AM EDT Last Seen Fri 13 Apr 2007 12:05:44 AM EDT Local ID 7d441cf2-8038-4f1b-9200-be0f4736767d Line Numbers Raw Audit Messages avc: denied { write } for comm="grub" dev=dm-0 egid=0 euid=0 exe="/sbin/grub" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="grub-install.log.UW4296" path="/tmp /grub-install.log.UW4296" pid=4298 scontext=user_u:system_r:bootloader_t:s0 sgid=0 subj=user_u:system_r:bootloader_t:s0 suid=0 tclass=file tcontext=user_u:object_r:tmp_t:s0 tty=pts0 uid=0 So I will try to go through verify my other installer bugs with SELinux enforcing off.
Switching to permissive SELinux gives the following: [root@localhost ~]# grub-install /dev/mapper/sil_ahaebidfbcbc /dev/mapper/sil_ahaebidfbcbc does not have any corresponding BIOS drive. So I suspect there are further issues with installing GRUB on this RAID 1 set.
anaconda is running in permissive mode, so the AVCs during anaconda aren't actually going to stop anything. Running anaconda in enforcing mode is a bit more of an overhaul than was feasible for F7. The other does seem more problematic. Did you try just seeing if it worked when rebooting instead of running grub-install manually? And are you running grub-install from within /mnt/sysimage or outside?
Fair enough ... I did set the LiveCD into permissive mode and manually activated my dmraid set (just in case) and finished an install just picking everything as default install options. On reboot it only got to the grub> prompt though so there are still things I need to sort out. I have the errors recorded at home when I tried to find the right path for 'root' and will comment them here later. So it is looking the grub is on the MBR now can't chain to its stages and find the root partition quite yet. I was just thinking of the LiveCD as a rescue disk when trying to force grub onto my RAID 1 MBR when I ran into grub problems previously. Not sure what you mean by inside or out as I didn't think the LiveCD found and mounted existing Linux installations. What I did was 'su -' in a terminal and ran the above commands as shown in in Comment #4. I do *not* mount the previously installed system with the broken MBR *nor* chroot at all. Maybe I will give that a try tonight (although I will have to look up the right mount command to mount default-LVM-structured, dmraided root/boot directories as I am just starting to figure LVM and dmraid out).
(In reply to comment #7) > On reboot it only got to the grub> prompt though so > there are still things I need to sort out. I have the errors recorded at home > when I tried to find the right path for 'root' and will comment them here later. The error that I was getting when tryingt o set a root on the GRUB command line was: Error 18: Selected cylinder exceeds maximum supported by BIOS Which is funny since it boots fine with one disk installed in exactly the same partition layout. So either something is amiss with GRUB/dmraid or my BIOS loses its mind when dealing with its own RAID 1 set.
This is working correctly now (at least with the original issue)