Bug 131187 - fstab-sync trashes /etc/fstab's SELinux context
Summary: fstab-sync trashes /etc/fstab's SELinux context
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Keywords:
: 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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-01 10:00:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

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

 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

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:

http://www.redhat.com/archives/fedora-selinux-list/2004-August/msg00204.html

Comment 6 David Zeuthen 2004-08-30 08:47:09 UTC
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.


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
root:object_r:etc_t.

Comment 8 David Zeuthen 2004-08-31 01:23:13 UTC
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.

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

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.