Bug 119408

Summary: "service <server> status" for unprivileged user with selinux enforcing
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: initscriptsAssignee: Daniel Walsh <dwalsh>
Status: CLOSED DEFERRED QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: eng-i18n-bugs, notting, wtogami
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 19:02:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 122683, 125997    

Description Jens Petersen 2004-03-30 06:58:19 UTC 
Description of problem:
With selinux in enforcing mode, system processes are
hidden from normal users. In particular "pidof <command>"
doesn't work for system processes.

A consequence of this is that a normal user
"/sbin/service <service> status" says the service
is stopped even if it is actually running.

How reproducible:
Every time

Steps to Reproduce:
0. Install test2 and login.
1. % service sshd status
2. % service canna status
3. su -
4. # service sshd status
5. # service canna status

Actual results:
1. sshd dead but pid file exists
2. cannaserver is stopped
4. sshd (pid 2536 2532 2068) is running...
5. cannaserver (pid 4541) is running...

Expected results:
Consist results.  If service can't tell the pids
of system processes to normal users, it should
say so (eg "Permission denied" or similar), rather
than giving inaccurate responses.

Additional comments:
The xinput script currently depends on service status output.
Canna comes with cannaping whose exit status corresponds to
whether cannaserver is running or not.  But implementing
"<service>ping" for every daemon in the distro seems like
a lot of work...
Comment 1 Jens Petersen 2004-04-14 08:39:45 UTC 
Any thoughts on this? :)
Comment 2 Daniel Walsh 2004-06-10 17:13:56 UTC 
Yeah, ouch.  I have no idea how to handle this other than to rewrite
the scripts.

Dan
Comment 3 Daniel Walsh 2004-09-30 19:02:06 UTC 
This really requires a rewrite of all service scripts to make it work
correctly, so I am deferring.

Dan
Comment 4 Eido Inoue 2004-09-30 19:54:55 UTC 
A rewrite of the "/etc/init.d/functions" file, which all (i think) of
the functions call to load up the helper routines, to check and abort
out with a "permission denied" or something along those lines, is all
that's necessary i think.