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 160294 - /var/spool/at/* isn't correct labeled - atd[...]: fgetfilecon FAILED
Summary: /var/spool/at/* isn't correct labeled - atd[...]: fgetfilecon FAILED
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-14 07:49 UTC by Robert Scheck
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-27 19:47:04 UTC


Attachments (Terms of Use)

Description Robert Scheck 2005-06-14 07:49:40 UTC
Description of problem:
/var/log/cron tells after enabling SELinux at executing an at job:
...
Jun 11 00:00:00 tux atd[8884]: fgetfilecon FAILED a001cd011c6f28: No data 
available
...

Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.23.18-5

How reproducible:
Everytime, see below.

Steps to Reproduce:
1. Disable SELinux and reboot the system
2. Submit an "at job" in the near future
3. Enable SELinux to targeted and set permissive or enforced
4. Do a "touch /.autolabel"
5. Reboot the system, wait for relabeling
6. Wait for executing of the at job, have a look to the system log
7. Will fail with the error written above.
  
Actual results:
The same problem also occurs at switching from targeted to strict and the 
other way round.

Expected results:
I'm absolutely no SELinux expert, but it seems for me, that /var/spool/at/* 
isn't labeled correct. I guess this can be solved in the corresponding SELinux 
policies...

Comment 1 Daniel Walsh 2005-06-15 18:58:33 UTC
What is the security context of the /var/spool/at?

ls -lZ /var/spool/at

Dan

Comment 2 Robert Scheck 2005-07-23 22:37:30 UTC
drwx------  daemon   daemon   system_u:object_r:cron_spool_t   .
drwxr-xr-x  root     root     system_u:object_r:var_spool_t    ..
-rw-------  root     root     root:object_r:cron_spool_t       .SEQ
drwx------  daemon   daemon   system_u:object_r:cron_spool_t   spool

Comment 3 Daniel Walsh 2005-07-25 13:12:26 UTC
That looks correct are you seeing any AVC messages in the log files?

Dan

Comment 4 Robert Scheck 2005-08-25 21:30:19 UTC
Nope, only what I already wrote in my first paragraph of this bug report:

Jun 11 00:00:00 tux atd[8884]: fgetfilecon FAILED a001cd011c6f28: No data 
available

Comment 5 Daniel Walsh 2005-09-22 14:58:28 UTC
This is happening when you convert from one policy to another, correct?  I think
the problem is there is a file context in /var/spool/at that the new policy does
not understand.  The file context has this line in it.

/var/spool/at/[^/]*    --      <<none>>

Which tells the apps not to relabel anything in the directory, because we have
no idea what to relabel it to.  Usually in /tmp and other places we advise
deleting these files.

Dan



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