Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-26 Thread Paul Eggert
Eric Blake <[EMAIL PROTECTED]> writes: > Would you accept a similar patch that splits out pipe-safer into its own > module instead of part of unistd-safer? I think that'd be OK, yes. It sounds pretty straightforward, anyway.

Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-26 Thread Paul Eggert
Ben Pfaff <[EMAIL PROTECTED]> writes: > I was worried that there was something bigger here. Usually a > "safety" issue is something more important than leaving a > temporary file undeleted or limiting their number, like the > possibility of a security hole, a segfault, etc. Eric Blake mentioned

Re: stdio-safer and tmpfile

2006-07-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 7/23/2006 7:23 AM: > > m4/ChangeLog: > 2006-07-23 Eric Blake <[EMAIL PROTECTED]> > > * unistd-safer.m4 (gl_UNISTD_SAFER): Check for missing pipe. > > 2006-07-23 Eric Blake <[EMAIL PROTECTED]> > > * pipe-sa

Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 7/26/2006 11:54 AM: > Eric Blake <[EMAIL PROTECTED]> writes: > >> According to Ben Pfaff on 7/25/2006 11:21 AM: >>> Can you expand on why tmpfile is not so safe? >> I'd still like to fear Paul's reasons. > > I hope you mea

Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-26 Thread Ben Pfaff
Eric Blake <[EMAIL PROTECTED]> writes: > According to Ben Pfaff on 7/25/2006 11:21 AM: >> Can you expand on why tmpfile is not so safe? > > I'd still like to fear Paul's reasons. I hope you mean "hear" them :-) > But one of mine is that tmpfile is allowed to leave a permanent > file behind if

Re: [bug-gnulib] split stdio-safer into fopen-safer, tmpfile-safer

2006-07-26 Thread Bruno Haible
Eric Blake wrote: > tmpfile is > allowed to leave a permanent file behind if the call to tmpfile() is > interrupted, or if the process _exit()s. Yet there is no way to know what > that file is. Yup. When you look at clean-temp.c you see the various steps that are needed to avoid leaving a file be

Re: [bug-gnulib] gettextize vs. gnulib?

2006-07-26 Thread Bruno Haible
Karl Berry wrote: > Given your updates to gettext in gnulib, I'm wondering about the > relationship of gnulib and gettextize (and autopoint, I guess). If a > packages uses the gettext module from gnulib, is it still necessary or > desirable to run gettextize? Or is gnulib sufficient? Good questi

Re: [bug-gnulib] purpose of *-safer?

2006-07-26 Thread Bruno Haible
Jim Meyering wrote: > Don't ever hide a conceptual write failure. > Reporting the error is the desired behavior. Thanks for explaining. Another argument, maybe, is that the kernel people wouldn't have invented /dev/null if you could get the same effect by closing the file descriptor. It all makes

Re: purpose of *-safer?

2006-07-26 Thread Jim Meyering
Bruno Haible <[EMAIL PROTECTED]> wrote: > Eric Blake wrote: >> POSIX requires [n]>&- and [n]<&- redirection operators to close >> the respective stream, even when n is 0, 1, or 2. POSIX allows an >> implementation to supply replacement file descriptors when exec'ing a >> setuid or setgid program.

Re: purpose of *-safer?

2006-07-26 Thread Bruno Haible
Eric Blake wrote: > POSIX requires [n]>&- and [n]<&- redirection operators to close > the respective stream, even when n is 0, 1, or 2. POSIX allows an > implementation to supply replacement file descriptors when exec'ing a > setuid or setgid program. But in the normal case, implementations reall

gettextize vs. gnulib?

2006-07-26 Thread Karl Berry
Hi Bruno, Given your updates to gettext in gnulib, I'm wondering about the relationship of gnulib and gettextize (and autopoint, I guess). If a packages uses the gettext module from gnulib, is it still necessary or desirable to run gettextize? Or is gnulib sufficient? Thanks, Karl