Bug 119408 - "service <server> status" for unprivileged user with selinux enforcing
Summary: "service <server> status" for unprivileged user with selinux enforcing
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 122683 IIIMF
TreeView+ depends on / blocked
 
Reported: 2004-03-30 06:58 UTC by Jens Petersen
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 19:02:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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