Someday we can move this to /port, but for now, let's get it into CVS.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
> >> Apparently it won't work at all if TMP isn't set?
>
> > I'm not *too* concerned about that, since TMP is normally set by the
OS
> > itself. There's one set in the "system environment" (to
c:\windows\temp
> > or whatrever) and then it's overridden by one set by the OS when it
> > loads a user
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> Apparently it won't work at all if TMP
>> isn't set?
> I'm not *too* concerned about that, since TMP is normally set by the OS
> itself. There's one set in the "system environment" (to c:\windows\temp
> or whatrever) and then it's overridden by one
> > Ok. Should be easy enough once the code is fine - can you
> comment on
> > the patch as sent, if the code itself looks right provided
> i wrap it
> > up in a function in port/?
>
> Not sure if the error handling is adequate --- are there any
> cases besides EEXIST that should loop?
Well,
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Ok. Should be easy enough once the code is fine - can you comment on the
> patch as sent, if the code itself looks right provided i wrap it up in a
> function in port/?
Not sure if the error handling is adequate --- are there any cases
besides EEXIST
> > I have repeated the problem with CVS head on XP SP2. It
> *does* create
> > it there (or rather, it tries to).
>
> > tmpnam() returns a file in the current dir per documentation, but I
> > see it generating one in the root instead.
> > tempnam() uses TMP environment variable.
>
> > tmpfile
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I have repeated the problem with CVS head on XP SP2. It *does* create it
> there (or rather, it tries to).
> tmpnam() returns a file in the current dir per documentation, but I see
> it generating one in the root instead.
> tempnam() uses TMP environ
> > If the implementation is such that it tries to create the file in a
> > directory that the user does not have write permission to,
> it's a bug.
>
> Well, I think it would be a valid implementation on Unix to
> always try to create the file in /tmp, which'd likely fail if
> someone had rev
From: Tom Lane <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] pg_dump -Ft failed on Windows XP
Date: Thu, 20 Apr 2006 10:00:48 -0400
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> >> Win32's tmpfile() creates the file into root folder. But
> >> non-
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If the implementation is such that it tries to create the file in a directory
> that the user does not have write permission to, it's a bug.
Well, I think it would be a valid implementation on Unix to always try
to create the file in /tmp, which'd lik
> >> Win32's tmpfile() creates the file into root folder. But
> >> non-administrator users can't create files into root folder.
>
> In other words, tmpfile() doesn't work at all on Win32?
> Seems like the appropriate place to be filing a bug report is
> at microsoft.com.
If works if you're an
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> Win32's tmpfile() creates the file into root folder. But
>> non-administrator users can't create files into root folder.
In other words, tmpfile() doesn't work at all on Win32? Seems like
the appropriate place to be filing a bug report is at micros
> > It's not buggy. It's well documented behaviour,and per my linux
> > manpage for the file it's also OK per spec:
> >
> >The standard does not specify the directory that tmpfile()
> >will use. Glibc will try the path prefix P_tmpdir defined
> >in , and if that fails the
Am Donnerstag, 20. April 2006 13:21 schrieb Magnus Hagander:
> It's not buggy. It's well documented behaviour,and per my linux manpage
> for the file it's also OK per spec:
>
>The standard does not specify the directory that tmpfile()
>will use. Glibc will try the path prefix P_tmpd
> > Question: Is the use of O_TEMPORARY to open() portable? (my
> win32 docs
> > say it will make the file automatically deleted when the last
> > descriptor is closed, which I didn't know before. That
> would make the
> > patch much simpler, but might require #ifdefs?)
>
> I think it would b
Am Donnerstag, 20. April 2006 13:03 schrieb Magnus Hagander:
> Question: Is the use of O_TEMPORARY to open() portable? (my win32 docs
> say it will make the file automatically deleted when the last descriptor
> is closed, which I didn't know before. That would make the patch much
> simpler, but mig
> > > Indeed, that's definitly a bug. Quick patch attached. It
> > does appear
> > > to work, but there may be a better way?
> >
> > This patch introduces a security hole because an attacker could
> > create, say, a suitable symlink between the time the name
> is generated
> > and the file is o
> > Indeed, that's definitly a bug. Quick patch attached. It
> does appear
> > to work, but there may be a better way?
>
> This patch introduces a security hole because an attacker
> could create, say, a suitable symlink between the time the
> name is generated and the file is opened.
Good po
Am Donnerstag, 20. April 2006 10:47 schrieb Magnus Hagander:
> Indeed, that's definitly a bug. Quick patch attached. It does appear to
> work, but there may be a better way?
This patch introduces a security hole because an attacker could create, say, a
suitable symlink between the time the name i
> I got the following message when I ran pg_dump with -Ft
> option on Windows XP.
>
> > pg_dump -V
> pg_dump (PostgreSQL) 8.1.2
>
> > pg_dump -Ft test > C:\backup\xxx.out
> pg_dump: [tar archiver] could not generate temporary file
> name: Permission denied
>
>
> pg_dump calls tmpfile() in pg_
20 matches
Mail list logo
