Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157322 - Cannot erase /halt file
Summary: Cannot erase /halt file
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-10 16:32 UTC by Ivan Gyurdiev
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-12 05:12:57 UTC

Attachments (Terms of Use)

Description Ivan Gyurdiev 2005-05-10 16:32:43 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3

Description of problem:
audit(1115741783.388:0): avc:  denied  { unlink } for  name=halt dev=dm-0 ino=16 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:root_t tclass=file

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:

Additional info:

Comment 1 Daniel Walsh 2005-05-10 18:05:19 UTC
restorecon /halt 

Any idea how this got created with the wrong context?


Comment 2 Ivan Gyurdiev 2005-05-10 18:28:55 UTC
What creates the halt file?

Comment 3 Daniel Walsh 2005-05-10 21:39:18 UTC
halt command creates this file.

The only way I can see this happening is executing the shutdown from gdm while
in permissive mode.


Comment 4 Ivan Gyurdiev 2005-05-10 22:29:18 UTC
It's entirely possible that I did that - I still turn off selinux all the time,
since it won't let me do various things - most notably I can't attach files
to mozilla, I can't run wine, and I can't run UT2003/4... 

...but why does permissive mode have this effect (w/ regard to halt file?).

Comment 5 Daniel Walsh 2005-05-11 10:06:23 UTC
Because there is a dontaudit rule instead of an allow,  now changing it to 

file_type_auto_trans(xdm_t, root_t, etc_runtime_t, file)

halt and poweroff both attempt to write a flag file to /

halt writes /halt and poweroff writes /poweroff

The /etc/init.d/halt script then has the following command

[ -f /poweroff -o ! -f /halt ] && HALTARGS="$HALTARGS -p"

exec $command $HALTARGS

Which either turns the poweroff on the machine or leaves it running.

At least that is the way I believe it is supposed to run.

Comment 6 Daniel Walsh 2005-05-11 10:17:28 UTC
rc.sysinit tries to delete these files on reboot.

grep poweroff /etc/rc.d/rc.sysinit
rm -f /fastboot /fsckoptions /forcefsck /.autofsck /halt /poweroff &> /dev/null

We have in policy now

file_type_auto_trans({ initrc_t sysadm_t }, root_t, etc_runtime_t, file)

So if the halt command is run by sysadm or via an init script it should get
created with the correct context.  Now if another application can write to the /
partition and executes halt, a file could get created with root_t.  But I don
not know of any.

grep " root_t.*dir.*write" policy.conf
allow bootloader_t root_t:dir { read getattr lock search ioctl add_name
remove_name write };
allow { initrc_t sysadm_t } root_t:dir { read getattr lock search ioctl add_name
remove_name write };
allow quota_t { root_t home_root_t var_t usr_t src_t var_spool_t }:dir { read
getattr lock search ioctl add_name remove_name write };
dontaudit xdm_t root_t:dir { add_name write };

bootloader and quotadb both transition files to bootloader_tmp_t and quota_db_t

I did add file context for /poweroff and a few other files the could be created in /

Comment 7 Ivan Gyurdiev 2005-05-12 05:12:57 UTC
Closing... will reopen if I see it again.

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