cvs commit: src/usr.bin/make job.c

[Alexander Leidinger]

Giorgos Keramidas <keramida at freebsd.org> wrote:

> Does this really need to be of the form DIR/fifo ?

No.

> I haven't looked at the code that uses the fifo at all, so I risk being
> extremely out of topic here, but why wouldn't a temporary fifo created
> with a name obtained from mkstemp() work too?

mkstemp() creates a file.

> A directory won't be needed if the fifo name is created by mkstemp() and
> then passed directly to mkfifo(2).

He wants to get rid of the tmpname() warning at link time, so he decided to
copy mkstemp() and modified the copy to create a fifo. I asked why he
doesn't use mkdtemp() so nobody has to care about synchronizing the code of
mkstemp() and his copy.

> Then there is still a (small?) possibility for a race, but a subsequent
> invocation of mkstemp() is almost guaranteed to work, unless mkstemp()
> is severely broken.

We don't talk about this kind of a race. We're talking about a malicious
programm hijacking the make-fifo. I don't think this is an issue, since the
malicious program has to be run with the same UID, and the you need to worry
about more important things than a DOS of make. And since a lot of people
download tarballs and run make without looking into the makefiles for
malicious content, such a simple DOS isn't worth a bikesheed (at least
IMHO).

Max already told me he will run the creation of the fifo in a loop. So if the
mkfifo() call fails because it already exists, he removes this fifo since he
hasn't created it. To be on the safe side I suggest to also print a
warning... and maybe to exit because this isn't supposed to happen.

I think this should cover our ass good enough.

Bye,
Alexander.

-- 
http://www.Leidinger.net/     Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org/        netchild @ FreeBSD.org  : PGP ID = 72077137
If I have to lay an egg for my country, I'll do it.
		-- Bob Hope