Bug 462090 - Make is leaking a file descriptor
Make is leaking a file descriptor
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: make (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-09-12 11:14 EDT by Daniel Walsh
Modified: 2015-05-04 21:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-22 07:25:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2008-09-12 11:14:26 EDT
Description of problem:

I am running with a confined ssh in Rawhide.  When executing make test-srpm or any make command within the Fedora infrastructure, make execs ssh for some reason.  This succeeds but generates the following avc every time.

type=AVC msg=audit(1221231878.677:50): avc:  denied  { read } for  pid=15221 comm="ssh" path="/home/dwalsh/src/devel/make/devel/Makefile" dev=dm-1 ino=771935 scontext=staff_u:staff_r:staff_ssh_t:s0 tcontext=staff_u:object_r:user_home_t:s0 tclass=file

Obviously ssh does not know about /home/dwalsh/src/devel/make/devel/Makefile and does not want to read it. The problem here is make has a open file descriptor to the Makefile with the read permission, when it forks/execs ssh SELinux checks all of the open file descriptors and closes them if the new confined domain does not access.  Generating the AVC above.

make should call

fcntl(fd, F_SETFD, FD_CLOEXEC) 

On any open file descriptor before the fork/exec
Comment 1 Petr Machata 2008-09-16 09:13:51 EDT
To reproduce this without involving other components, I assume the descriptor leaked by make should be world visible.  So I have the following suite:

$ cat mk 
all:;./x.py

$ cat x.py 
#!/usr/bin/env python
import os
os.system("ls -ls /proc/%d/fd" % os.getpid())

Now when I run the makefile:

$ make -f ./mk 
./x.py
total 0
0 lrwx------ 1 ant ant 64 2008-09-16 13:43 0 -> /dev/pts/21
0 lrwx------ 1 ant ant 64 2008-09-16 13:43 1 -> /dev/pts/21
0 lrwx------ 1 ant ant 64 2008-09-16 13:43 2 -> /dev/pts/21
0 lr-x------ 1 ant ant 64 2008-09-16 13:43 4 -> pipe:[539480]
0 l-wx------ 1 ant ant 64 2008-09-16 13:43 5 -> pipe:[539480]
0 lr-x------ 1 ant ant 64 2008-09-16 13:43 6 -> /home/ant/GNUstep/Defaults

... I don't see anything suspicious, save the GNUstep file that's probably inherited from WindowMaker.  This matches what I see when I run ./x.py directly.

I was poking into that from various directions, creating big or small makefile, including other makefiles, etc., but couldn't make make to not close the file.  When I strace the invocation, it shows opens and closes paired up nicely near each other.  In the source, fclose is inevitable in eval_makefile: only when I comment out that fclose do I see x.py reporting the makefile.

Besides I can't find any reference to ssh or scp in fedora makefiles.

I'm also trying directly on rawhide machine (enforcing mode), but can't reproduce it.  Is there any extra setup to be done?  The installation has:
  selinux-policy-targeted-3.5.7-1.fc10.noarch
  selinux-policy-3.5.7-1.fc10.noarch
Comment 2 Daniel Walsh 2008-09-16 09:40:15 EDT
I see this as a possible candidate.
strace -f /tmp/out Makefile
vi /tmp/out
...
open("Makefile", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=838, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f87f38bb000
read(3, "# Makefile for source rpm: selinu"..., 4096) = 838
pipe([4, 5])                            = 0
vfork()                                 = 8003
close(5)                                = 0
read(4, "../common/Makefile.common\n"..., 200) = 26

It is forking with the file descriptor 3 still open.  I think all that is needed here is the fcntl call. 

If you wanted to set this up on a test machine you would have to setup your login account to be staff_u.

semanage login -a -s staff_u pmachata

Logout log back in, you should be now running as staff_u and you will transision to staff_ssh_t when you run the ssh command.
Comment 3 Petr Machata 2008-09-16 10:41:37 EDT
Ah, it leaks through $(shell).  And fcntl indeed fixes that.
Comment 4 Petr Machata 2008-09-22 07:25:13 EDT
make-3.81-14.fc10 has been built, which contains the fix.

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