Red Hat Bugzilla – Bug 145901
selinux denies use of /dev/tty
Last modified: 2013-07-02 23:03:51 EDT
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): selinux-policy-targeted-1.17.30-2.73 kernel-2.6.10-1.741_FC3 How reproducible: 100% Steps to Reproduce: 1. See above. 2. 3. Actual results: No output. Expected results: Version message as requested by -V flag. Additional info: Forced relabel via /.autorelabel does not help.
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
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
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?
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. Dan
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 him.
I don't know, did he get some AVC messages? Dan
I'll close this as "fixed rawhide" for now, unless I get some evidence about a reproducible problem in FC3 current.