Messaging and GCC - "use of `mktemp' is dangerous" warning

[Brendan]

Hi,

I'm trying to mimic the IPC/messaging system of an specific OS in a
portable way by using GCC's library. The IPC system uses buffered
asynchronous messages, where any thread can send a message to any other
thread (i.e. to the "threadID") without blocking, and the receiver does
any security checks necessary.

I'm trying to implement the portable/linux version on top of
sockets/datagrams ("SOCK_DGRAM" in the local namespace), and so far
it's working. The first problem I had is that you can't send a datagram
directly to a PID. To get around this, each process creates a temporary
file for it's socket. When any process is created the file name it's
parent used is passed as a command line argument ("excl"), and the new
process uses this information to send an "init" message back to it's
parent containing the file name it used for it's socket. When the
parent receives this "init" message, it broadcasts a "new process"
message to all previous processes within the application. It's an ugly
mess, but after all processes have started (and built a "directory" of
message port ID's) it does work like the IPC system I'm trying to
mimic.

To allow several instances of the application to run at the same time
(without file name conflicts), I'm using the "mktemp" function to
create unique file names for each process's socket.

Unfortunately, GCC keeps reporting warnings - "warning: the use of
`mktemp' is dangerous, better use `mkstemp'".

Is there a way to do this more securely or more cleanly? The "mkstemp"
function isn't quite the same as "bind", and using "mkstemp" and then
closing/deleting the file before calling "bind" seems stupid (it's just
as insecure and messier).

Alternatively, is there a way to disable this warning? For an open
source project, it's a little embarassing when the compiler decides to
tell others that your code is "dangerous" (especially if there is no
viable alternative)....
Thanks,

Brendan

[Jack Klein]

On 1 May 2006 12:38:35 -0700, "Brendan" <bt******@gmail.com> wrote in
comp.lang.c:

Hi,

I'm trying to mimic the IPC/messaging system of an specific OS in a
portable way by using GCC's library. The IPC system uses buffered
asynchronous messages, where any thread can send a message to any other
thread (i.e. to the "threadID") without blocking, and the receiver does
any security checks necessary.

I'm trying to implement the portable/linux version on top of
sockets/datagrams ("SOCK_DGRAM" in the local namespace), and so far
it's working. The first problem I had is that you can't send a datagram
directly to a PID. To get around this, each process creates a temporary
file for it's socket. When any process is created the file name it's
parent used is passed as a command line argument ("excl"), and the new
process uses this information to send an "init" message back to it's
parent containing the file name it used for it's socket. When the
parent receives this "init" message, it broadcasts a "new process"
message to all previous processes within the application. It's an ugly
mess, but after all processes have started (and built a "directory" of
message port ID's) it does work like the IPC system I'm trying to
mimic.

To allow several instances of the application to run at the same time
(without file name conflicts), I'm using the "mktemp" function to
create unique file names for each process's socket.

Unfortunately, GCC keeps reporting warnings - "warning: the use of
`mktemp' is dangerous, better use `mkstemp'".

Is there a way to do this more securely or more cleanly? The "mkstemp"
function isn't quite the same as "bind", and using "mkstemp" and then
closing/deleting the file before calling "bind" seems stupid (it's just
as insecure and messier).

Alternatively, is there a way to disable this warning? For an open
source project, it's a little embarassing when the compiler decides to
tell others that your code is "dangerous" (especially if there is no
viable alternative)....
Thanks,

Brendan

None of sockets, threads, IPC, PID, or mkstemp are defined by or part
of the standard C library. I would suggest you post this either to a
gcc support group, or one for programming for that "specific OS" that
you were careful not to mention.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Brendan]

Hi,

Jack Klein wrote:

None of sockets, threads, IPC, PID, or mkstemp are defined by or part
of the standard C library. I would suggest you post this either to a
gcc support group, or one for programming for that "specific OS" that
you were careful not to mention.

I've reposted to "gnu.gcc.help" - I haven't created any newsgroups for
the OS that I was careful not to mention.
Cheers,

Brendan

[Igmar Palsenberg]

Brendan wrote:

Hi, To allow several instances of the application to run at the same time
(without file name conflicts), I'm using the "mktemp" function to
create unique file names for each process's socket.
mktemp() is dangerous, since it allows an attacker to guess names.

Unfortunately, GCC keeps reporting warnings - "warning: the use of
`mktemp' is dangerous, better use `mkstemp'".
The linker is actually reporting this.
Is there a way to do this more securely or more cleanly? The "mkstemp"
function isn't quite the same as "bind", and using "mkstemp" and then
closing/deleting the file before calling "bind" seems stupid (it's just
as insecure and messier).
Isn't tempnam() an alternative ?
Alternatively, is there a way to disable this warning? For an open
source project, it's a little embarassing when the compiler decides to
tell others that your code is "dangerous" (especially if there is no
viable alternative)....

No, not that I'm aware of.

Igmar

[Brendan]

Hi,

Igmar Palsenberg wrote:

Brendan wrote:

To allow several instances of the application to run at the same time
(without file name conflicts), I'm using the "mktemp" function to
create unique file names for each process's socket.
mktemp() is dangerous, since it allows an attacker to guess names.

The mktemp() function *may* be used in an insecure way, but it can also
be used securely and there's plenty of warnings about the problem in
the library manuals. It seems I'm also not the first to have this
problem. An example, from
http://kt.dlut.edu.cn/samba/sm20001223_36.html:

"Despite the stupid compiler warnings mktemp() (when used properly) is
the most secure option available. When something better comes along we
can consider using it, but meanwhile just put up with the stupid
compiler warnings."

To be honest, for my code there's is a tiny window of time between the
mktemp() call and bind() call that immediately follows it where an
attacker could cause bind() to fail. In this case the application will
shutdown on startup with a "failed to initialized communications" error
(no data loss, etc). It's entirely acceptable considering the
application itself.
Isn't tempnam() an alternative ?

The tempnam() function is re-entrant while mktemp() isn't (which
doesn't matter for me as each process only uses it once anyway).
Otherwise they are mostly equivelent, and I still get a "warning: the
use of `tempnam' is dangerous, better use `mkstemp'" warning.

I have thought of one possibility - I could use "mkdtemp" to securely
create a temporary directory, and then create the files used for
sockets in this directory. In this case the file names won't matter and
don't need to be random. It's annoying, but it'd stop the linker's
whining (which solves my problem)... :-)
Thanks,

Brendan

[void * clvrmnky()]

Brendan wrote:

Hi,

Igmar Palsenberg wrote:

Brendan wrote:

To allow several instances of the application to run at the same time
(without file name conflicts), I'm using the "mktemp" function to
create unique file names for each process's socket.

mktemp() is dangerous, since it allows an attacker to guess names.

The mktemp() function *may* be used in an insecure way, but it can also
be used securely and there's plenty of warnings about the problem in
the library manuals. It seems I'm also not the first to have this
problem. An example, from
http://kt.dlut.edu.cn/samba/sm20001223_36.html:

"Despite the stupid compiler warnings mktemp() (when used properly) is
the most secure option available. When something better comes along we
can consider using it, but meanwhile just put up with the stupid
compiler warnings."

To be honest, for my code there's is a tiny window of time between the
mktemp() call and bind() call that immediately follows it where an
attacker could cause bind() to fail. In this case the application will
shutdown on startup with a "failed to initialized communications" error
(no data loss, etc). It's entirely acceptable considering the
application itself.

Isn't tempnam() an alternative ?

The tempnam() function is re-entrant while mktemp() isn't (which
doesn't matter for me as each process only uses it once anyway).
Otherwise they are mostly equivelent, and I still get a "warning: the
use of `tempnam' is dangerous, better use `mkstemp'" warning.

I have thought of one possibility - I could use "mkdtemp" to securely
create a temporary directory, and then create the files used for
sockets in this directory. In this case the file names won't matter and
don't need to be random. It's annoying, but it'd stop the linker's
whining (which solves my problem)... :-)

[OT]
Isn't there an option to GCC to ask it to shut up about certain warnings?

[Brendan]

Hi,

void * clvrmnky() wrote:

[OT]
Isn't there an option to GCC to ask it to shut up about certain warnings?

Yes - there's lots of command line options that enable or disable
specific types of warnings. AFAIK every "enable" option has a
corresponding "disable" option (which is normally the same with a "no-"
inserted) - for example, "Wunused-function" and "-Wno-unused-function".

As Igmar correctly pointed out, the "mktemp()" warnings are from the
linker and not from GCC. As far as I"ve been able to find out there is
no way to enable/disable these warnings - they're like a big permanent
glowing sign proclaiming that I'm a moron and that the code is
"dangerous" (which is why I've spent the last 4 hours modifying my
"compatibility layer").

[Even more OT]

To be honest, it's working out better than I thought it would - I'm
using the "message port ID" as the file name for each socket, which
means I don't need to send a "new process started" broadcast message
anymore (and makes it easier to hide the legacy environment from the
application).
Cheers,

Brendan