Bug 131187 - fstab-sync trashes /etc/fstab's SELinux context
Summary: fstab-sync trashes /etc/fstab's SELinux context
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
: 131413 (view as bug list)
Depends On:
Blocks: FC3Target FC3Blocker
TreeView+ depends on / blocked
Reported: 2004-08-28 16:58 UTC by W. Michael Petullo
Modified: 2013-03-06 03:41 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-01 10:00:27 UTC

Attachments (Terms of Use)
Output from "hald --daemon=no --verbose=yes" (41.66 KB, text/plain)
2004-08-30 01:28 UTC, W. Michael Petullo
no flags Details

Description W. Michael Petullo 2004-08-28 16:58:04 UTC
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):

How reproducible:

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:

Comment 1 David Zeuthen 2004-08-28 17:12:33 UTC
Thanks for the report. I'll look into this.

Comment 2 Tom London 2004-08-28 21:11:22 UTC
Glad I checked before I filed.... 

I'm seeing this too with hal-0.2.97.cvs20040827-3.

Comment 3 David Zeuthen 2004-08-29 22:22:04 UTC
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


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).


Comment 4 David Zeuthen 2004-08-29 22:50:02 UTC
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.

Comment 5 W. Michael Petullo 2004-08-30 01:28:46 UTC
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:


Comment 6 David Zeuthen 2004-08-30 08:47:09 UTC
OK, here we go again, please try 


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.

Comment 7 W. Michael Petullo 2004-08-31 00:43:44 UTC
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

Comment 8 David Zeuthen 2004-08-31 01:23:13 UTC
Alright, I think I know what is wrong, please try with this one


if it doesn't work please post the output of 'fstab-sync -c -v' (the
-v is important). Much thanks.

Comment 9 David Zeuthen 2004-08-31 01:29:24 UTC
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

(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).

Comment 10 W. Michael Petullo 2004-08-31 02:38:43 UTC
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.

Comment 11 David Zeuthen 2004-09-01 10:00:27 UTC
I've built hal-0.2.97.cvs20040901-1 into Rawhide with this fix - I'll
keep the atomic issue with in mind. Thanks.

Comment 12 David Zeuthen 2004-09-01 10:05:51 UTC
*** Bug 131413 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.