Bug 119408 - "service <server> status" for unprivileged user with selinux enforcing
"service <server> status" for unprivileged user with selinux enforcing
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: i18n
Depends On:
Blocks: 122683 IIIMF
  Show dependency treegraph
Reported: 2004-03-30 01:58 EST by Jens Petersen
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:02:06 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 Jens Petersen 2004-03-30 01:58:19 EST
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 04:39:45 EDT
Any thoughts on this? :)
Comment 2 Daniel Walsh 2004-06-10 13:13:56 EDT
Yeah, ouch.  I have no idea how to handle this other than to rewrite
the scripts.

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

Comment 4 Eido Inoue 2004-09-30 15:54:55 EDT
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.