bug#6330: Feature request: mktemp creates named pipes

[Eric Blake]

On 06/03/2010 01:09 PM, Sebastien Andre wrote:
> I see two reasons why the addition of a --fifo option is better than using
> existing tools:
> 
>     * Creating a temporary directory to finally create a pipe just because
> it is safe this way is kind of a trick. For the clarity of scripts, it would
> be better having mktemp to ensure the uniqueness of a fifo, even if it's
> created in /

Why do you need to create fifos directly in /?  Unless you can prove
that it is needed there, then what's wrong with creating it elsewhere?
Maybe the real feature we should be asking for is a way to ensure that
'mv /path1/to/fifo /path2/to/fifo' is atomic, and fails if
/path2/to/fifo is a dangling symlink rather than accidentally creating
the fifo at an unintended location?

> 
>     * mktemp is not only a tool to create unique files, it's also a name
> generator. The example given in the manual works for one or two fifos, but
> if the number of fifos is unknown there is no choice but implementing
> something to generate names, which is another potential source of bugs.

If you are worried about creating lots of fifos, and want to avoid
collisions, you can still use the existing semantics of unpatched mktemp
to get that: merely make a secure directory with mktemp -d, then use
mkfifo "$(mktemp -u -p "$dir")".  That is, once you have a safe
directory, then mktemp -u within that directory is no longer a security
hole, and serves as a great way to create unique names without also
creating files.

> of $i to ensure unicity of fifo names. If for any reason $tmpdir must be
> shared with other processes which use the exact same function it will
> lead to a mess, that's why I prefer merge_output_mktempfifo().

As long as the multiple processes are closely cooperating, and all use
the same secure temporary directory, then mktemp -u is an appropriate
way for each of those processes to name their fifo.

>> Patches speak volumes, although by the time you add the code and the
>> documentation, your contribution would probably be non-trivial and
>> require copyright assignment to the FSF.  Let us know if you'd like to
>> start that process.
>>
>>
> Yes, I'm interested in starting that process.

I'm sending you some details off-list.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature