Linux-Development-Apps Digest #427, Volume #7 Wed, 23 May 01 18:13:10 EDT
Contents:
Re: How to get rid of 'tempnam is dangerous' warning? (Grant Edwards)
Re: How to get rid of 'tempnam is dangerous' warning? (Grant Edwards)
Re: Just a little program, but I get a warning, why? (Grant Edwards)
Platform-specific preprocessor symbols automatically defined by gcc
([EMAIL PROTECTED])
Re: HELP: I want to statically link libstdc++ to a .so (Adam Fineman)
Re: Platform-specific preprocessor symbols automatically defined by gcc (Erik Max
Francis)
Re: How to get rid of 'tempnam is dangerous' warning? (John Hasler)
freebsd sockets interface ("TdC")
Re: How to use semaphore? ([EMAIL PROTECTED])
USENIX 2001 Annual Technical Conference (Tiffany Peoples)
Re: How to get rid of 'tempnam is dangerous' warning? (Philip Armstrong)
Safe to call from a signal handler? ("Bob Ert")
Re: How to get rid of 'tempnam is dangerous' warning? (Nate Eldredge)
Re: Platform-specific preprocessor symbols automatically defined by gcc (Nate
Eldredge)
Re: Safe to call from a signal handler? (Adam Fineman)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: How to get rid of 'tempnam is dangerous' warning?
Date: Wed, 23 May 2001 15:10:08 GMT
In article <9een6h$1kf$[EMAIL PROTECTED]>, Philip Armstrong wrote:
>In article <kfyO6.3272$[EMAIL PROTECTED]>,
>Grant Edwards <[EMAIL PROTECTED]> wrote:
>>But warning me when I'm _not_ using it in a way that's causing
>>a security problem is just generating noise and extra work.
>
>*shrug*
>
>tmpnam() is a security disaster.
No, it isn't.
When you use the results of tempnam() in a certain manner, there
is a security risk.
>Warning about it in the linker makes
>sure that no current programmer can avoid seeing the warning about it
>being used in code they compile. That seems reasonable to me. Anyone
>who needs that functionality and knows that what they are doing isn't
>a security hole can roll their own.
Which is what I did.
The other thing that I thought was odd was that the warning
message says to use mkstmp() as a replacement, but mkstmp()
doesn't do the same thing as tempnam() and therefor can't be
used as a replacement.
--
Grant Edwards grante Yow! .. over in west
at Philadelphia a puppy is
visi.com vomiting...
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: How to get rid of 'tempnam is dangerous' warning?
Date: Wed, 23 May 2001 15:11:29 GMT
In article <[EMAIL PROTECTED]>, William Morris wrote:
>Philip Armstrong <[EMAIL PROTECTED]> wrote:
>
>> tmpnam() is a security disaster. Warning about it in the linker makes
>> sure that no current programmer can avoid seeing the warning about it
>> being used in code they compile. That seems reasonable to me. Anyone
>> who needs that functionality and knows that what they are doing isn't
>> a security hole can roll their own.
>
>
>Ok I'm feeling distinctly left out now. If I have the following
>in tmpnam.c:
>
>#include <stdio.h>
>int
>main( int argc, char * argv[] )
>{
> printf( "tmpnam = %s\n", tmpnam(NULL));
> printf( "tempnam = %s\n", tempnam("/tmp", "hello"));
> return 0;
>}
>
>and I compile like:
>
>debian ~/tmp > gcc -Wall -o tmpnam tmpnam.c
>debian ~/tmp >
>
>I get no warning. What am I missing?
>
>debian ~/tmp > gcc -v
>Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
>gcc version 2.95.2 20000220 (Debian GNU/Linux)
I only get the warning under RH7.1. If it's a warning from the
linker, then it must be the linker or libc version that matters.
--
Grant Edwards grante Yow! .. bleakness....
at desolation.... plastic
visi.com forks...
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Just a little program, but I get a warning, why?
Date: Wed, 23 May 2001 15:13:48 GMT
In article <[EMAIL PROTECTED]>, charles guo wrote:
>I try the 'hello' kernel module program
>When I load it. It show a warning. My kernel is version 2.2.16-22
>
>>Insmod -f hello.o
>Warning:kernel-module version mismatch
> hello.o was compiled for kernel version 2.4.0-0.26
> while this kernel is version 2.2.16-22
>
>why it say hello.o was compiled for kernel version 2.4.0-0.26
I'm guessing you're using RH7.0? If so, then either upgrade to
7.1 or downgrade to 6.2. 7.0 is broken in many, many ways.
The one you just found is that the kernel headers installed by
RH 7.0 don't match the kernel binaries that are installed:
You've got kernel 2.4 sources, but are running a 2.2 kernel.
Never use an x.0 release from RedHat. I'm generally skeptical
of x.1 releases also.
--
Grant Edwards grante Yow! I'm using my X-RAY
at VISION to obtain a rare
visi.com glimpse of the INNER
WORKINGS of this POTATO!!
------------------------------
Subject: Platform-specific preprocessor symbols automatically defined by gcc
From: [EMAIL PROTECTED]
Date: 23 May 2001 12:35:58 -0500
I am looking for documentation outlining standard preprocessor symbols
that are automatically defined by gcc/g++ when building source files on
a Linux system.
Is it safe to assume that the "__linux__" is automatically defined by the
compiler on a Linux system ? Typing "gcc -dM -E - < /dev/null" shows
that a number of linux-related symbols are automatically defined by gcc:
@matrix:[/home/ssahmed] gcc -dM -E - < /dev/null
#define __linux__ 1
#define linux 1
#define __i386__ 1
#define __i386 1
#define __GNUC_MINOR__ 95
#define i386 1
#define __unix 1
#define __unix__ 1
#define __GNUC__ 2
#define __linux 1
#define __ELF__ 1
#define unix 1
Should I use __linux__ or linux or __linux ?
What is the preferred (ie canonical) way of including platform-specific
code when using gcc/g++ together with autoconf and automake ?
Thanks.
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: HELP: I want to statically link libstdc++ to a .so
Date: Wed, 23 May 2001 12:57:01 -0400
Mike Huculak wrote:
>
> Dear linker experts,
>
> I am using gcc 2.95.2 with libstdc++ version 3 because it is thread
> safe. The problem is that RedHat 6.2 does not distribute this compiler
> and libc++ version and it is pain for others to install.
>
Actually, it's not that bad.
> What I am looking for is a way to write c++ applications with
> compilers that use the common version 2 of c++
>
What do you mean by 'the common version 2 of c++'? I assume that you
are talking about a compiler or a library, but you need to be more
clear.
> and still be able to
> link to my library. My idea is to statically link my .so and use a
> version script to hide all the symbols except the ones in my API.
>
> Can anyone tell me if this is possbile?
>
I'm not 100% sure of what you're trying to do. Are you building a
library for others to use, or applications?
> Thanx,
>
> Mike
>
> Here is what i tried (and failed)
> =================================
>
> To link my .so (c++) I did:
>
> g++ -I../i386-linux/include -I../i386-linux/../include -D_i386_
> -D_linux_ -D_SIMPLE_R -D_REENTRANT -D_GNU_SOURCE -D__THREADED
> -L../i386-linux/thirdparty -L../i386-linux/libthr --version-script
> CppLib.ver -static -fPIC -shared build/i386-linux/obj.so/_version.o
> build/i386-linux/obj.so/CppLib.o \
> -o build/i386-linux/obj.so/libCppLib.so. -lAnotherStaticLib
>
> to verify libc++ got statically linked (it is also a lot bigger this
> way):
>
> > ldd build/i386-linux/obj.so/libCppLib.so.
> libm.so.6 => /lib/libm.so.6 (0x400c6000)
> libc.so.6 => /lib/libc.so.6 (0x400e3000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
> To link my C only app I did (using the same gcc):
>
> g++ -I../i386-linux/include -I../i386-linux/../include -D_i386_
> -D_linux_ -D_SI
> MPLE_R -D_REENTRANT -D_GNU_SOURCE -D__THREADED -L../i386-linux/lib
> -L../i386-li
> nux/libthr -lc -ldl -pthread -g build/i386-linux/obj/_version.o
> build/i386-lin
> ux/obj/MyTestApp.o -o build/i386-linux/obj/MyTestApp -lCppLib
>
> Even though the app is only C it still requires libc++ (can't
> understand why):
>
That _version.o file, is it built from C++ code? Was it built with g++
(as opposed to gcc)? What error do you actually get if you compile with
gcc (not g++) and don't link to CppLib?
> > ldd build/i386-linux/obj/MyTestApp
> libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
> libCppLib.so =>
> /users/mhuculak/libconflict/i386-linux/lib/libCppLib.so (0x4001e000)
> libstdc++.so.3 =>
> /usr/localbin/gcc-2.95.2-libstdc++-2.90.8-posix/lib/libstdc++.so.3
> (0x400de000)
> libm.so.6 => /lib/libm.so.6 (0x401d2000)
> libc.so.6 => /lib/libc.so.6 (0x401f0000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x402e5000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> And when I try to run the app, it dies a miserable death (no usefull
> stack trace). If I remove the "-static" flag when I link my .so the
> app works. Removing the version script does not keep the app from seg
> faulting.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: Platform-specific preprocessor symbols automatically defined by gcc
Date: Wed, 23 May 2001 09:51:08 -0700
[EMAIL PROTECTED] wrote:
> What is the preferred (ie canonical) way of including
> platform-specific
> code when using gcc/g++ together with autoconf and automake ?
I would recommend using your own.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Time is a storm in which we are all lost.
\__/ George Bernard Shaw
7 sisters productions / http://www.7sisters.com/
Web design for the future.
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Subject: Re: How to get rid of 'tempnam is dangerous' warning?
Date: Wed, 23 May 2001 16:31:57 GMT
Grant Edwards writes:
> The other thing that I thought was odd was that the warning message says
> to use mkstmp() as a replacement, but mkstmp() doesn't do the same thing
> as tempnam() and therefor can't be used as a replacement.
It can't be used as a direct replacement, but in most cases minimal changes
are required.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
From: "TdC" <no#[EMAIL PROTECTED]#spam>
Subject: freebsd sockets interface
Date: Wed, 23 May 2001 19:08:42 GMT
Hey,
My machine has multiple ips, how i can make my C++ program use another ip?
Thanks,
TdC
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to use semaphore?
Date: 23 May 2001 19:13:58 GMT
Piscean <[EMAIL PROTECTED]> wrote:
> Yes,I have known semaphore is a good idea in synchronization between
> processes.But how to implement that?Is it enough to use semget(),semop()and
> semctl()?In addition,what should a process do when it wait to get a
> semaphore?
semget(), semop() and semctl() are all the functions you probably will
need. Here is a set of functions I am using to synchronize two processes:
============8<=============================================================
#include <sys/ipc.h>
#include <sys/sem.h>
/* Needed because of some broken stuff in older Linux versions... */
#if defined ( _SEM_SEMUN_UNDEFINED ) && ( _SEM_SEMUN_UNDEFINED == 1 )
union semun {
int val; /* value for SETVAL */
struct semid_ds *buf; /* buffer for IPC_STAT, IPC_SET */
unsigned short int *array; /* array for GETALL, SETALL */
struct seminfo *__buf; /* buffer for IPC_INFO */
};
#endif
/*------------------------------------------------------------*/
/* Function creates a (System V) semaphore (with one set) and */
/* initializes it to 0. It returns either the ID number of */
/* the new semaphore or -1 on error. */
/*------------------------------------------------------------*/
int sema_create( void )
{
int sema_id;
union semun sema_arg;
if ( ( sema_id = semget( IPC_PRIVATE, 1,
IPC_CREAT | IPC_EXCL | SEM_R | SEM_A ) ) < 0 )
return -1;
sema_arg.val = 0;
if ( ( semctl( sema_id, 0, SETVAL, sema_arg ) ) < 0 )
{
semctl( sema_id, 0, IPC_RMID, sema_arg );
return -1;
}
return sema_id;
}
/*--------------------------------------------------------------*/
/* Function deletes the semaphore with the ID number 'sema_id'. */
/* It returns 0 on success and -1 on error. */
/*--------------------------------------------------------------*/
int sema_destroy( int sema_id )
{
union semun sema_arg;
if ( semctl( sema_id, 0, IPC_RMID, sema_arg ) < 0 )
return -1;
return 0;
}
/*-------------------------------------------------------------------------*/
/* Function waits until the value of the semapore with ID number 'sema_id' */
/* becomes greater than 0 (and then decrement the semaphore by 1). It */
/* returns 0 on success and -1 on errors. The function will not return */
/* but continue to wait when signals are received. */
/*-------------------------------------------------------------------------*/
int sema_wait( int sema_id )
{
struct sembuf wait = { 0, -1, 0 };
while ( semop( sema_id, &wait, 1 ) < 0 )
if ( errno != EINTR )
return -1;
return 0;
}
/*------------------------------------------------------------------*/
/* Function increments the semaphore with ID number 'sema_id' by 1. */
/* It returns 0 on success and -1 on errors. */
/*------------------------------------------------------------------*/
int sema_post( int sema_id )
{
struct sembuf post = { 0, 1, 0 };
if ( semop( sema_id, &post, 1 ) < 0 )
return -1;
return 0;
}
============8<=============================================================
While a process is waiting for a semaphore it's not doing anything at all,
it will be stopped while waiting and other processes will be run in between.
HTH, Jens
--
_ _____ _____
| ||_ _||_ _| [EMAIL PROTECTED]
_ | | | | | | AG Moebius, Institut fuer Molekuelphysik
| |_| | | | | | Fachbereich Physik, Freie Universitaet Berlin
\___/ens|_|homs|_|oerring Tel: ++49 (0)30 838 - 53394 / FAX: - 56046
------------------------------
From: Tiffany Peoples <[EMAIL PROTECTED]>
Subject: USENIX 2001 Annual Technical Conference
Date: Wed, 23 May 2001 12:39:58 -0700
2001 USENIX Annual Technical Conference
June 25-30, 2001
Marriott Copley Place Hotel
Boston, Massachusetts, USA
http://www.usenix.org/events/usenix01/
==============================================
REGISTER BY May 25, 2001 and Save up to $200!
==============================================
Join peers, research and industry leaders in Boston at the USENIX Annual
Technical Conference.
FEATURING THIRTY professional-level tutorials, SEVENTEEN brand-new!
Herešs a sampling:
Running Web Servers Securely Internet Security for Linux Sys Admins
Network Security Profiles UNIX Network Programming
Network Programming with Perl Inside the Linux Kernel
Building Linux Applications Large Heterogeneous Networks
Practical Wireless IP Security Exploring the Potential of LDAP
Wireless Networking Fundamentals Configuring & Administering Samba
Servers
* KEYNOTE ADDRESS by Daniel D. Frye, Director of IBM Linux Technology
Center.
* INVITED TALKS on WAP, IP Wireless Networking, Security Aspects of
Napster and Gnutella, Security For E-voting in Public Elections, Virtual
Machines, Online Privacy, Active Content and Secure DNS
*NEWLY ADDED CLOSING SESSION with Cynthia Breazeal, researcher from the
MIT media lab, currently developing robots that can duplicate human
facial emotions.
*VENDOR EXHIBITION featuring innovative companies, products and
services.
For more information on exhibiting, please contact Dana Geffner at
[EMAIL PROTECTED]
For more information and to register, visit:
http://www.usenix.org/events/usenix01/
=====================================================================
The 2001 USENIX Annual Technical Conference is sponsored by
USENIX, the Advanced Computing Systems Association. www.usenix.org
=====================================================================
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: How to get rid of 'tempnam is dangerous' warning?
Date: 23 May 2001 20:26:59 +0100
In article <[EMAIL PROTECTED]>,
William Morris <[EMAIL PROTECTED]> wrote:
>debian ~/tmp > gcc -Wall -o tmpnam tmpnam.c
>debian ~/tmp >
>
>I get no warning. What am I missing?
phil@kantaka ~/testing >gcc -Wall -o tmpnam tmpnam.c
/tmp/ccEMKgYo.o: In function `main':
/tmp/ccEMKgYo.o(.text+0xf): the use of `tmpnam' is dangerous, better
use `mkstemp'
/tmp/ccEMKgYo.o(.text+0x37): the use of `tempnam' is dangerous, better
use `mkstemp'
Debian unstable as of yesterday.
It's a linker thing. I don't know when the message was
introducted. Probably in glibc 2.2
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: "Bob Ert" <[EMAIL PROTECTED]>
Subject: Safe to call from a signal handler?
Date: Wed, 23 May 2001 22:19:13 +0100
Hi all,
Is there a list somewhere of functions that are safe to call from within a
signal handler in Linux?
Many thanks. :)
------------------------------
From: Nate Eldredge <[EMAIL PROTECTED]>
Subject: Re: How to get rid of 'tempnam is dangerous' warning?
Date: 23 May 2001 14:37:04 -0700
[EMAIL PROTECTED] (Grant Edwards) writes:
> In article <[EMAIL PROTECTED]>, William Morris
>wrote:
> >Philip Armstrong <[EMAIL PROTECTED]> wrote:
> >
> >> tmpnam() is a security disaster. Warning about it in the linker makes
> >> sure that no current programmer can avoid seeing the warning about it
> >> being used in code they compile. That seems reasonable to me. Anyone
> >> who needs that functionality and knows that what they are doing isn't
> >> a security hole can roll their own.
> >
> >
> >Ok I'm feeling distinctly left out now. If I have the following
> >in tmpnam.c:
> >
> >#include <stdio.h>
> >int
> >main( int argc, char * argv[] )
> >{
> > printf( "tmpnam = %s\n", tmpnam(NULL));
> > printf( "tempnam = %s\n", tempnam("/tmp", "hello"));
> > return 0;
> >}
> >
> >and I compile like:
> >
> >debian ~/tmp > gcc -Wall -o tmpnam tmpnam.c
> >debian ~/tmp >
> >
> >I get no warning. What am I missing?
> >
> >debian ~/tmp > gcc -v
> >Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
> >gcc version 2.95.2 20000220 (Debian GNU/Linux)
>
> I only get the warning under RH7.1. If it's a warning from the
> linker, then it must be the linker or libc version that matters.
Both, actually. The function has associated with it some weird ELF
feature (an "unallocated section", whatever that is) containing a
message. Sufficiently recent GNU ld knows that when it sees this, it
should print out the message. The compiler is irrelevant.
I'm currently using glibc 2.2.1 and ld 2.10 and it works. I think it
used to work with glibc 2.1.3 and ld 2.9.
Search for "link_warning" in include/libc-symbols.h in the glibc
source if you want gory details of the libc side. I don't know
offhand where in the ld source the linker's part lives.
--
Nate Eldredge
[EMAIL PROTECTED]
------------------------------
From: Nate Eldredge <[EMAIL PROTECTED]>
Subject: Re: Platform-specific preprocessor symbols automatically defined by gcc
Date: 23 May 2001 14:39:44 -0700
Erik Max Francis <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
> > What is the preferred (ie canonical) way of including
> > platform-specific
> > code when using gcc/g++ together with autoconf and automake ?
>
> I would recommend using your own.
What do you mean by this? Your own way of including platform-specific
code, i.e. any way you want?
I also have a problem like this, and I'd rather not write my own
hackish solution if I can use one that already exists :) But if not,
well then, I might as well get to it.
--
Nate Eldredge
[EMAIL PROTECTED]
------------------------------
From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: Safe to call from a signal handler?
Date: Wed, 23 May 2001 17:48:29 -0400
Bob Ert wrote:
>
> Hi all,
>
> Is there a list somewhere of functions that are safe to call from within a
> signal handler in Linux?
>
> Many thanks. :)
Yes, in Programming with POSIX Threads, by D. Butenhof. In my version
it's on p.235.
You could buy the book (it's a great book, I think), or maybe you could
find it on Google.
--
Adam
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-Apps Digest
******************************
