From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.2) Gecko/20040809 Epiphany/1.3.5 Description of problem: Running fstab-sync causes the SELinux context of /etc/fstab to go from system_u:object_r:etc_t to root:object_r:tmp_t. This causes system boots to fail when SELinux is enforcing Fedora's strict policy. The boot process fails when it tries to run fsck. Version-Release number of selected component (if applicable): hal-0.2.97.cvs20040827-2 How reproducible: Always Steps to Reproduce: [root@imp default]# ls -lZ /etc/fstab -rw-r--r-- root root system_u:object_r:etc_t /etc/fstab [root@imp default]# fstab-sync -c [root@imp default]# ls -lZ /etc/fstab -rw-r--r-- root root root:object_r:tmp_t /etc/fstab [root@imp default]# restorecon /etc/fstab [root@imp default]# ls -lZ /etc/fstab -rw-r--r-- root root system_u:object_r:etc_t /etc/fstab Expected Results: Running fstab-sync should not change the SELinux context of /etc/fstab. Additional info:
Thanks for the report. I'll look into this.
Glad I checked before I filed.... I'm seeing this too with hal-0.2.97.cvs20040827-3.
Alright, I've added support for this in fstab-sync. I don't have a selinux system available presently, so please try this fstab-sync binary here http://freedesktop.org/~david/selinux/ it's for i386; let me know if you use another architecture and I'll build some RPMS insteads. Should this not work, please include the output of 'hald --daemon=no verbose=yes' running as root (remember to stop the haldaemon service). Thanks, David
I just saw that you are using PPC (at least your browser suggests that), so I've just uploaded a SRPM to the location given above (built at my local box). If it looks good I'll put this into Rawhide, so please let me know how it works out.
Created attachment 103224 [details] Output from "hald --daemon=no --verbose=yes" I just tried hal-0.2.97.cvs20040830-1 and the problem remains. I verified that fstab-sync is linked against libselinux. This has also been talked about on the fedora-selinux mailing list: http://www.redhat.com/archives/fedora-selinux-list/2004-August/msg00204.html
OK, here we go again, please try http://freedesktop.org/~david/selinux/hal-0.2.97.cvs20040830-2.src.rpm Now we don't create the temporary file in /tmp but rather in /etc. Please give a 'ls -lZ /etc/fstab' and hald dump if this still fails. Much thanks.
Here are the results with hal-0.2.97.cvs20040830-2: [root@imp /]# ls -lZ /etc/fstab -rw-r--r-- root root system_u:object_r:etc_t /etc/fstab [root@imp /]# fstab-sync -c /etc/fstab [root@imp /]# ls -lZ /etc/fstab -rw-r--r-- root root root:object_r:etc_t /etc/fstab [root@imp /]# restorecon /etc/fstab [root@imp /]# ls -lZ /etc/fstab -rw-r--r-- root root system_u:object_r:etc_t /etc/fstab This is closer but now we switch from system_u:object_r:etc_t to root:object_r:etc_t.
Alright, I think I know what is wrong, please try with this one http://people.redhat.com/davidz/hal-0.2.97.cvs20040831-1.src.rpm if it doesn't work please post the output of 'fstab-sync -c -v' (the -v is important). Much thanks.
Btw, I implemented this using code from restorecon to save a fork+exec and possible error paths; does this mean that fstab-sync will require some extra privs to relabel files? Is this the recommended way to do this? (FWIW, I have to rename a tmp file in /etc to /etc/fstab to achieve atomicity in the update; but now that I need to do the restorecon thing this no longer appears atomic on selinux; we may fail between rename(2) and restorecon, right? Hmm).
hal-0.2.97.cvs20040831-1 seems to fix things. I did get the following SELinux-related log (SELinux is not currently enforcing my policy -- only checking): Aug 30 21:36:02 imp kernel: audit(1093919762.305:0): avc: denied { read } for pid=15888 exe=/usr/sbin/fstab-sync path=pipe:[20827] dev=pipefs ino=20827 scontext=root:system_r:updfstab_t tcontext=user_u:user_r:user_su_t tclass=fifo_file Aug 30 21:36:02 imp fstab-sync[15888]: removed all generated mount points ...but it seems dbus, udev and crew in general have a lot of issues with the current strict policy anyway. It seems that there is a lot of copy and pasting of code from restorecon.c. It's unfortunate if there is no higher level function to do something that seems this fundamental. I would also be interested in seeing comment on the atomic issue raised in comment #9.
I've built hal-0.2.97.cvs20040901-1 into Rawhide with this fix - I'll keep the atomic issue with in mind. Thanks.
*** Bug 131413 has been marked as a duplicate of this bug. ***