[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #57242] Non-recursive command passes invalid jobserver file descrip
From: |
R. Diez |
Subject: |
[bug #57242] Non-recursive command passes invalid jobserver file descriptors |
Date: |
Tue, 12 Jan 2021 08:16:17 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0 |
Follow-up Comment #7, bug #57242 (project make):
About this statement below:
"This is necessary, because a command can mess up job server operation or a
command may expect a specific fd to be available."
a) I wonder how a command can mess up job server operation:
a1) One way would be that a program is looking at all open file descriptors it
inherited, and messing with them. I am not sure whether we want to make the
job server robust against such attacks.
a2) Another way is that the program has a bug and is not using the job server
properly. But I do not think that this scenario is worth much consideration
either.
b) If one really wants to stop inheriting the job server and the associated
flag, I wonder whether a makefile can filter out the job server options from
MAKEFLAGS.
I am actually doing the opposite, I am fetching the jobserver flags from
MAKEFLAGS and letting only those through. Check out variable
EXTRACT_SELECTED_FLAGS_FROM_MAKEFLAGS in this makefile:
https://github.com/rdiez/JtagDue/blob/master/Toolchain/Makefile
Would it be possible to use GNU Make function $(filter-out pattern...,text) to
remove the job server options?
c) I wonder how "a command may expect a specific fd to be available".
A while ago I wanted a way to always pass down the jobserver file
descriptors:
Passing jobserver file descriptors to all children
https://lists.gnu.org/archive/html/help-make/2020-02/msg00000.html
I encountered a similar statement then:
"Originally make did pass these file descriptors to all children, but there
were bugs filed because some tools invoked by make expected to have specific
file descriptors available; having make pass down open FDs caused them to
fail."
Can someone provide more detail about which file descriptors a program may
expect to be available? Because that is generally considered bad practice, as
far as I know.
If this mainly refers to Bash scripts, I found in its manual page that Bash
seems to use descriptors above 10 internally, as only the low 10 seem
guarantee stability for scripts:
"Redirections using file descriptors greater than 9 should be used with care,
as they may conflict with file descriptors the shell uses internally."
Maybe if GNU Make moved those job server descriptors to higher numbers, like
Bash does internally, there would be less problems in this area. I cannot
imagine that some program or script may assume that file descriptor number
12,345 must be available right now. But maybe I am missing something, I am no
expert in this area.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?57242>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #57242] Non-recursive command passes invalid jobserver file descriptors,
R. Diez <=