On Wed, Jul 18, 2007 at 12:19:20AM +0200, Ralf S. Engelschall wrote:
> On Wed, Jul 18, 2007, Dmitry V. Levin wrote:
> > On Tue, Jul 17, 2007 at 11:35:04PM +0200, Ralf S. Engelschall wrote:
> > > On Tue, Jul 17, 2007, Ralf S. Engelschall wrote:
> > > > On Tue, Jul 17, 2007, Ralf S. Engelschall wrote:
> > > > > On Tue, Jul 17, 2007, Jeff Johnson wrote:
> > > > > [...]
> > > > > So what? Fix the temporary file handling a better way or at least get
> > > > > rid of the bogus code or really keep it to further test the hacker index
> > > > > of developers who hack on RPM?
> > > > > [...]
> > > >
> > > > Oh, sorry, I see. I've compared too much with the code in lib/misc.c
> > > > but overlooked that there is an "#ifndef NOTYET" (note the "n" and not
> > > > a "#ifdef NOTYET". Ok, forget my previous reply. I missed the fact that
> > > > mktemp(3) itself is still needed, of course. Well, then then why arent't
> > > > why at least use the close(mkstemp()) hack consistenty throughout the
> > > > RPM code? In build.c there is this workaround, in lib/rpmchecksig.c it
> > > > isn't, etc. Any reasons for this?
> > >
> > > So, what about this to make the stuff at least consistent and at the
> > > same time finally get rid of the mktemp(3) linker warnings?
> >
> > No, please do not apply this change.
> > The problem is real, so let linker warnings remind us about this issue.
> 
> _IF_ the problem is really _REAL_ in RPM then why has nobody fixed it
> until now? If it is real then one should really _FIX_ the problem and
> not watch for the linker warnings popping up for more years... ;-)

Temporary files created this way, especially by makeTempFile() function,
are usually passed by name to external executables.  That is, the issue
does not look like easy to fix.

Whether these temp file issues are real or not?  It depends on directory
locations where files are created.  You may say that %_specdir and %_tmppath
should not be accessable by outsiders, but there are no warranty.
Also, rpmReSign() function may be executed to create temporary file in a
writable directory.


-- 
ldv