Red Hat Bugzilla – Bug 498181
Lots of selinux denials from foomatic
Last modified: 2009-04-30 04:56:36 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 2.6.29.1-111.fc11.x86_64 #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): foomatic-4.0.0-2.fc11.x86_64 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 :)
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).
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.
So what does 'ls -Zd /usr /usr/local /usr/local/bin' say?
% 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. :(