Bug 462090 - Make is leaking a file descriptor
Summary: Make is leaking a file descriptor
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: make
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Petr Machata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F10Blocker, F10FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2008-09-12 15:14 UTC by Daniel Walsh
Modified: 2015-05-05 01:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-22 11:25:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Daniel Walsh 2008-09-12 15:14:26 UTC
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 13:13:51 UTC
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 13:40:15 UTC
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 14:41:37 UTC
Ah, it leaks through $(shell).  And fcntl indeed fixes that.

Comment 4 Petr Machata 2008-09-22 11:25:13 UTC
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.