Bug 145901 - selinux denies use of /dev/tty
selinux denies use of /dev/tty
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-01-23 11:49 EST by Tom Lane
Modified: 2013-07-02 23:03 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-27 20:05:53 EST
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 Tom Lane 2005-01-23 11:49:32 EST
Description of problem:
$ sudo /usr/sbin/setenforce 0
$ /usr/bin/postgres -V
postgres (PostgreSQL) 8.0.0

$ sudo /usr/sbin/setenforce 1
$ /usr/bin/postgres -V

/var/log/messages shows
Jan 23 11:38:22 rh1 kernel: audit(1106498302.606:0): avc:  denied  { getattr } for  
pid=4998 exe=/usr/bin/postgres path=/dev/pts/1 dev=devpts ino=3 scontext=user_u:
system_r:postgresql_t tcontext=user_u:object_r:devpts_t tclass=chr_file

This is really not acceptable ...

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

How reproducible:

Steps to Reproduce:
1. See above.
Actual results:
No output.

Expected results:
Version message as requested by -V flag.

Additional info:
Forced relabel via /.autorelabel does not help.
Comment 1 Tom Lane 2005-01-23 11:59:05 EST
BTW: before blowing this off as a trivial cosmetic issue, consider that help output is also 
suppressed (eg, postgres -h) and that it seems to affect all daemons not only postgres --- 
for instance try
/usr/sbin/named -h
Comment 2 Daniel Walsh 2005-01-24 14:57:26 EST
This is addressed in the rawhide policy, although it is fairly
difficult to fix in FC-3.  You can just pipe to cat to get the output.

/usr/bin/postgres -V | cat
postgres (PostgreSQL) 8.0.0

Comment 3 Tom Lane 2005-01-24 15:44:37 EST
The original complaint had to do with failing to obtain the -V output
from a popen() call, ie, popen("/usr/bin/postgres -V") returned zero
bytes.  I couldn't reproduce this locally; is it likely that some
prior version of the policy had that problem?
Comment 4 Daniel Walsh 2005-01-24 15:48:55 EST
Are you running rawhide policy?  Rawhide policy has fixed this problem
in that policy only takes effect when apps are run by init scripts. 
If you run a exe by hand it should not run in the protected domain. 
Moving this into FC3/RHEL4 is quite dangerous though, since extensive
changes in policy were required to make this happen.  If this becomes
a big problem in RHEL, I might have to make some major changes.

Comment 5 Tom Lane 2005-01-24 16:12:21 EST
No, this is all on FC3.  I'm running the currently released FC3
policy, and the original complainant said he was running FC3 also,
but I suppose it must have been an earlier policy version.

As long as the popen() case doesn't fail, this isn't a "must fix" as
far as Postgres is concerned; but I'd like to know why it did fail for
Comment 6 Daniel Walsh 2005-01-26 12:57:08 EST
I don't know, did he get some AVC messages?

Comment 7 Tom Lane 2005-01-27 20:05:53 EST
I'll close this as "fixed rawhide" for now, unless I get some evidence about a
reproducible problem in FC3 current.

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