Bug 498181 - Lots of selinux denials from foomatic
Lots of selinux denials from foomatic
Product: Fedora
Classification: Fedora
Component: foomatic (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-29 06:39 EDT by Mary Ellen Foster
Modified: 2009-04-30 04:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-30 04:56:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mary Ellen Foster 2009-04-29 06:39:59 EDT
Description of problem:
I just tried using system-config-printer to add a new printer, and just choosing the "New Printer" menu item resulted in a spew of selinux denials. I'll include the details of one of the 198:

SELinux is preventing foomatic (cupsd_t) "search" mnt_t.
Additional Information
Source Context:  system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context:  unconfined_u:object_r:mnt_t:s0
Target Objects:  local [ dir ]Source:  cups-driverd
Source Path:  /usr/lib/cups/daemon/cups-driverd
Port:  <Unknown>
Host:  snape
Source RPM Packages:  perl-5.10.0-68.fc11
Target RPM Packages:  
Policy RPM:  selinux-policy-3.6.12-9.fc11
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  catchall
Host Name:  snape
Platform:  Linux snape #1 SMP Fri Apr 24 10:57:09 EDT 2009 x86_64 x86_64
Alert Count:  198
First Seen:  Wed 29 Apr 2009 11:14:05 AM BST
Last Seen:  Wed 29 Apr 2009 11:26:24 AM BST
Local ID:  09cf4cfd-3d68-4e34-8508-126c027123a8
Line Numbers:  
Raw Audit Messages :
node=snape type=AVC msg=audit(1241000784.925:125): avc: denied { search } for pid=2680 comm="foomatic" name="local" dev=sda7 ino=13 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mnt_t:s0 tclass=dir
node=snape type=SYSCALL msg=audit(1241000784.925:125): arch=c000003e syscall=4 success=no exit=-1543348264 a0=2375dc8 a1=7fffc6b41a90 a2=7fffc6b41a90 a3=352f6c7265705f65 items=0 ppid=2678 pid=2680 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm="foomatic" exe="/usr/bin/perl" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) 

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

How reproducible:
Every time

Steps to Reproduce:
1. Run system-config-printer
2. Choose Server-New-Printer
3. Enter root password
Actual results:
Lots of AVC denials (about 100 each time)

Expected results:
No denials :)
Comment 1 Tim Waugh 2009-04-29 12:28:07 EDT
This sounds more like a local configuration problem.  Do you perhaps have a filesystem mounted at /usr/local, and does that filesystem's root inode have 'mnt_t' as its security type?  That directory is meant to be type usr_t so that applications can look in /usr/local/bin as part of the normal $PATH traversal (for instance).
Comment 2 Mary Ellen Foster 2009-04-30 04:15:01 EDT
Aha, yes, good point -- I have one partition for "/" and another, mounted on "/hd", with the following bind mounts:
- "/hd/home" mounted at "/home"
- "/hd/local" mounted at "/usr/local"

The labels on /hd/home and /hd/local are (now) correct, I think:
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /hd/home
drwxr-xr-x. root root system_u:object_r:usr_t:s0       /hd/local

But you're right, the label on /hd itself is:
drwxr-xr-x. root root system_u:object_r:default_t:s0   /hd

I guess this partitioning scheme doesn't play nice with selinux. :( I've always disabled selinux before, so I didn't notice, but this time I left it enabled and I guess this is the result.
Comment 3 Tim Waugh 2009-04-30 04:45:31 EDT
So what does 'ls -Zd /usr /usr/local /usr/local/bin' say?
Comment 4 Mary Ellen Foster 2009-04-30 04:56:36 EDT
% ls -Zd /usr /usr/local /usr/local/bin
drwxr-xr-x. root root system_u:object_r:usr_t:s0       /usr
drwxr-xr-x. root root system_u:object_r:usr_t:s0       /usr/local
drwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/local/bin

But I'm sorry for the spam -- after booting this morning, the problem seems to have gone away. I guess all of my frantic relabelling yesterday did in fact solve things after all, and it just needed a fresh boot to see things right.

Sorry about that. :(

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