Created attachment 515231 [details] tester script Description of problem: I'm getting an avc denial when I run newaliases (on a postfix mail server) from within a lock (done by flock) in a script Version-Release number of selected component (if applicable): libselinux-utils-1.33.4-5.7.el5 selinux-policy-2.4.6-300.el5_6.1 libselinux-1.33.4-5.7.el5 libselinux-python-1.33.4-5.7.el5 libselinux-1.33.4-5.7.el5 selinux-policy-targeted-2.4.6-300.el5_6.1 How reproducible: always Steps to Reproduce: 1. run the attached tester script 2. 3. Actual results: see attached logs.txt Expected results: no avc denial Additional info: I don't know why in god's name postalias would want to touch the lockfile. That's quite illogical.
Created attachment 515232 [details] logs.txt
You either redirected stdout to /tmp/tester.runlock or you leaked an open file descriptor from the program that opened /tmp/tester.runlock. You need to close all open file descriptors on exec fcntl(fd, F_SETFD, FD_CLOEXEC)
Dan, how would I do that? (please look at the script)
If you change ) 200>"${lockFile}" to ) 200 | cat >"${lockFile}" I think you will eliminate the AVC.
(In reply to comment #4) > If you change > > ) 200>"${lockFile}" > > to > > ) 200 | cat >"${lockFile}" unfortunately this is unsupported by bash. pipes can only deal with stdout and stderr. so I have to use > I could do ') 200>&1 | ..' but the the output within the block does not show on the screen (obviously)
#!/bin/bash set -e set -u declare -i lockWaitSeconds=10 declare lockFile="/var/spool/postfix/tester.runlock" >$lockFile ( # Wait for lockfile (fd 200) for lockWaitSeconds seconds set +e flock -e -w "${lockWaitSeconds}" 200 declare -i lockResult=$? set -e if [[ ${lockResult} -ne 0 ]]; then echo "Could not aquire lock" exit 1 fi # run program in lock newaliases ) 200>>"${lockFile}"
The above script should work. I moved your runlock file to /var/spool/postfix, and precreated it. Then I just use append rather then write for the script.
Created attachment 516385 [details] newaliases trace log file I tested your modifications and the only thing that really has an effect is moving the lockfile into /var/spool/postfix This is logical from the SELinux point of view but I still don't understand why the h*&l newaliases touches the filedescriptor 200 (which it doesn't own). I did an strace of newaliases inside the lock but can't really see that it touches the lockfile. I _do_ see strange behaviour on line 229 of the attached strace log file. I find moving the file into /var/spool/postfix rather ugly and a workaround only. It seems there is a bug somewhere inside newaliases.
this has _not_ been resolved
If I understand correctly, the remaining issue is with newaliases.
well, maybe... I don't have enough knowledge of selinux internals to know whether it is selinux or newaliases or flock or whatever else to determine who is touching those file descriptors.
Are you getting AVC msgs?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.