Re: [HACKERS] Possible make_oidjoins_check Security Issue
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: On Wed, 2004-10-20 at 06:18, Rod Taylor wrote: http://secunia.com/advisories/12860/ This seems like a rather inconsequential problem, Indeed, since ordinary users have no use for make_oidjoins_check. It's surely very implausible that anyone would run it as root; and even if someone did, the attacker cannot control what gets written. but it should be fixed. The first two ideas that come to mind: use temporary files in $PWD rather than /tmp, or create a subdirectory in /tmp to use for the temporary files. I believe that the subdirectory idea is also vulnerable without great care. I believe the proper way to handle this is a new directory under /tmp. I use this in my local scripts: TMP=/tmp/$$ OMASK=`umask` umask 077 if ! mkdir $TMP thenecho Can't create temporary directory $TMP. 12 exit 1 fi umask $OMASK unset OMASK It basically makes sure it creates a new directory under /tmp with a umask that guarantees no one else can create a file in that directory. All temp files are accessed as $TMP/XXX. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible make_oidjoins_check Security Issue
Bruce Momjian [EMAIL PROTECTED] writes: I believe the proper way to handle this is a new directory under /tmp. It's definitely not worth the trouble. I looked at what configure does to make /tmp subdirectories portably, and it is spectacularly ugly (not to mention long). If make_oidjoins_check were a user-facing tool that would be one thing, but it isn't ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible make_oidjoins_check Security Issue
Tom Lane wrote: I suspect that no one on the planet except Bruce and myself have ever actually run this script. Then why don't we just remove it? Problem solved ... cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Possible make_oidjoins_check Security Issue
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I suspect that no one on the planet except Bruce and myself have ever actually run this script. Then why don't we just remove it? Problem solved ... Because it's a needed maintenance tool. There isn't any particularly good reason for it to get installed as though it were an interesting program for users, though, so I think that this is mostly a matter of poor packaging choices. I am in fact intending to remove the contrib/findoidjoins files from the set of stuff installed by Red Hat's RPMs. I suppose you could make an argument for moving this directory out of contrib and putting it under src/tools instead, but that seems like more work (and loss of CVS history) than it's worth. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Possible make_oidjoins_check Security Issue
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I suspect that no one on the planet except Bruce and myself have ever actually run this script. Then why don't we just remove it? Problem solved ... Because it's a needed maintenance tool. There isn't any particularly good reason for it to get installed as though it were an interesting program for users, though, so I think that this is mostly a matter of poor packaging choices. I am in fact intending to remove the contrib/findoidjoins files from the set of stuff installed by Red Hat's RPMs. I suppose you could make an argument for moving this directory out of contrib and putting it under src/tools instead, but that seems like more work (and loss of CVS history) than it's worth. Then maybe there's a case for removing findoidjoins from WANTED_DIRS in contrib/Makefile? I agree this issue is so trifling that it's not worth spending much energy on. On a very slightly related note, I see that ipcclean (which is a shell script) is installed on Windows by make install. Do we want to fix that or trust the binary packagers to remove it? cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Possible make_oidjoins_check Security Issue
http://secunia.com/advisories/12860/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Possible make_oidjoins_check Security Issue
On Wed, 2004-10-20 at 06:18, Rod Taylor wrote: http://secunia.com/advisories/12860/ This seems like a rather inconsequential problem, but it should be fixed. The first two ideas that come to mind: use temporary files in $PWD rather than /tmp, or create a subdirectory in /tmp to use for the temporary files. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible make_oidjoins_check Security Issue
On Wed, Oct 20, 2004 at 12:52:57PM +1000, Neil Conway wrote: On Wed, 2004-10-20 at 06:18, Rod Taylor wrote: http://secunia.com/advisories/12860/ This seems like a rather inconsequential problem, but it should be fixed. The first two ideas that come to mind: use temporary files in $PWD rather than /tmp, or create a subdirectory in /tmp to use for the temporary files. Better, use mktemp(1). The thread testing script already does it IIRC. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Un poeta es un mundo encerrado en un hombre (Victor Hugo) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Possible make_oidjoins_check Security Issue
Neil Conway [EMAIL PROTECTED] writes: On Wed, 2004-10-20 at 06:18, Rod Taylor wrote: http://secunia.com/advisories/12860/ This seems like a rather inconsequential problem, Indeed, since ordinary users have no use for make_oidjoins_check. It's surely very implausible that anyone would run it as root; and even if someone did, the attacker cannot control what gets written. but it should be fixed. The first two ideas that come to mind: use temporary files in $PWD rather than /tmp, or create a subdirectory in /tmp to use for the temporary files. I believe that the subdirectory idea is also vulnerable without great care. My inclination so far as the Red Hat packages are concerned is simply to omit the contrib/findoidjoins files from the installed RPMs. The patch originally proposed by trustix involved using mktemp(1), which would be a great fix if mktemp(1) weren't so laughably unportable :-( But in any case it's hard to see why we are expending RPM distro space on this script in the first place. I suspect that no one on the planet except Bruce and myself have ever actually run this script. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Possible make_oidjoins_check Security Issue
Alvaro Herrera [EMAIL PROTECTED] writes: Better, use mktemp(1). The thread testing script already does it IIRC. There are only two uses of mktemp(1) in our source tree: configure and config.guess. Both were gotten from elsewhere, and both jump through some seriously unreadable hoops in order to achieve allegedly-portable behavior. mktemp(1) is simply not portable :-( ... the Single Unix Spec refuses to touch it at all ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Possible make_oidjoins_check Security Issue
On Wed, Oct 20, 2004 at 12:31:11AM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Better, use mktemp(1). The thread testing script already does it IIRC. There are only two uses of mktemp(1) in our source tree: configure and config.guess. Both were gotten from elsewhere, and both jump through some seriously unreadable hoops in order to achieve allegedly-portable behavior. Huh, right. I was remembering mkstemp(3), which is used in the thread test (which is not a script after all ...) config.guess usage surely is ugly ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Porque francamente, si para saber manejarse a uno mismo hubiera que rendir examen... ¿Quién es el machito que tendría carnet? (Mafalda) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
