Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
On Tue, Dec 11, 2007 at 08:58:05AM -0500, Andrew Dunstan wrote: > >I'm actually inclined to vote with Stephen that this is a silly change. > >I just put up the patch to show the best way of doing it if we're gonna > >do it ... > > OK. I'm not going to die in a ditch over it. On the other hand, warning about it in the docs would probably be a good idea... -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 pgpqQC74CaoF8.pgp Description: PGP signature
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: It's also worth noting that we haven't removed the PGPASSWORD environment variable, even though that's demonstrably insecure on some platforms. True. But at least its use is deprecated. The reason I put in PGPASSFILE was to tempt (so far unsuccessfully) the maintainers of a certain well known application to stop using PGPASSWORD. I'm actually inclined to vote with Stephen that this is a silly change. I just put up the patch to show the best way of doing it if we're gonna do it ... OK. I'm not going to die in a ditch over it. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Magnus Hagander wrote: > On Mon, Dec 10, 2007 at 10:47:19PM -0500, Tom Lane wrote: > If we want to prevent it for psql, we should actually prevent it *in* psql, > not in libpq. There are an infinite number of scenarios where it's > perfectly safe to put the password there... If we want to do it share, we > should add a function like PQSanitizeConnectionString() that will remove > it, that can be called from those client apps that may be exposing it. > > There are also platforms that don't show the full commandline to other > users - or even other processes - that aren't affected, of course. One idea is to have psql "hide" the password on the ps status. That way it becomes less of a security issue. It would still be a problem on certain operating systems, but at least several common platforms would be covered. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ Officer Krupke, what are we to do? Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke") ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
On Mon, Dec 10, 2007 at 10:47:19PM -0500, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > Stephen Frost wrote: > >> I'm going to have to vote 'silly' on this one. > > > It's a matter of being consistent. If we think such a facility shouldn't > > be provided on security grounds, then we shouldn't allow it via a > > backdoor, ISTM. > > Well, the problem with this approach is that libpq has no real means > of knowing whether a string it's been passed was exposed on the command > line or not. dbName might be secure, and for that matter the conninfo > string passed to PQconnectdb might be insecure. Should we put in > arbitrary restrictions on the basis of hypotheses about where these > different arguments came from? > > It's also worth noting that we haven't removed the PGPASSWORD > environment variable, even though that's demonstrably insecure on some > platforms. > > I'm actually inclined to vote with Stephen that this is a silly change. > I just put up the patch to show the best way of doing it if we're gonna > do it ... +1 on the silly. If we want to prevent it for psql, we should actually prevent it *in* psql, not in libpq. There are an infinite number of scenarios where it's perfectly safe to put the password there... If we want to do it share, we should add a function like PQSanitizeConnectionString() that will remove it, that can be called from those client apps that may be exposing it. There are also platforms that don't show the full commandline to other users - or even other processes - that aren't affected, of course. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Stephen Frost wrote: >> I'm going to have to vote 'silly' on this one. > It's a matter of being consistent. If we think such a facility shouldn't > be provided on security grounds, then we shouldn't allow it via a > backdoor, ISTM. Well, the problem with this approach is that libpq has no real means of knowing whether a string it's been passed was exposed on the command line or not. dbName might be secure, and for that matter the conninfo string passed to PQconnectdb might be insecure. Should we put in arbitrary restrictions on the basis of hypotheses about where these different arguments came from? It's also worth noting that we haven't removed the PGPASSWORD environment variable, even though that's demonstrably insecure on some platforms. I'm actually inclined to vote with Stephen that this is a silly change. I just put up the patch to show the best way of doing it if we're gonna do it ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Anybody think this is good, bad, or silly? Does the issue need explicit documentation, and if so where and how? I'm going to have to vote 'silly' on this one. While I agree that in general we should discourage, and not provide explicit command-line options for, passing a password on the command-line, I don't feel that it makes sense to explicitly complicate things to prevent it. It's a matter of being consistent. If we think such a facility shouldn't be provided on security grounds, then we shouldn't allow it via a backdoor, ISTM. cheers andrew ---(end of broadcast)--- TIP 1: 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: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: Tom Lane wrote: As of PG 8.3, libpq allows a conninfo string to be passed in via the dbName parameter of PQsetdbLogin. I didn't even know we could do that. I always use the shell variable option instead. Does anyone actually use the facility? Well, not yet, because it's new in 8.3 ... Yeah, let's not do that. Like you said, "While we cannot absolutely prevent client apps from doing stupid things, it seems like it might be a good idea to prevent passwords from being passed in through dbName. " To me... this is something that if we allow, people will use it, and we will end up removing it, realizing it is a bad idea. There are plenty of other ways to pass the password in a more sane way. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
* Tom Lane ([EMAIL PROTECTED]) wrote: > Anybody think this is good, bad, or silly? Does the issue need > explicit documentation, and if so where and how? I'm going to have to vote 'silly' on this one. While I agree that in general we should discourage, and not provide explicit command-line options for, passing a password on the command-line, I don't feel that it makes sense to explicitly complicate things to prevent it. Just my 2c, Thanks, Stephen signature.asc Description: Digital signature
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> As of PG 8.3, libpq allows a conninfo string to be passed in via the >> dbName parameter of PQsetdbLogin. > I didn't even know we could do that. I always use the shell variable > option instead. Does anyone actually use the facility? Well, not yet, because it's new in 8.3 ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: As of PG 8.3, libpq allows a conninfo string to be passed in via the dbName parameter of PQsetdbLogin. This is to allow access to conninfo facilities in old programs that are still using PQsetdbLogin (including most of our own standard clients ... ahem). For instance psql "service = foo" Andrew Dunstan pointed out a possible security hole in this: it will allow people to do psql "dbname = mydb password = mypassword" which would leave their password exposed on the program's command line. While we cannot absolutely prevent client apps from doing stupid things, it seems like it might be a good idea to prevent passwords from being passed in through dbName. The attached patch (which depends on some pretty-recent changes in CVS HEAD) accomplishes this. Anybody think this is good, bad, or silly? Does the issue need I didn't even know we could do that. I always use the shell variable option instead. Does anyone actually use the facility? explicit documentation, and if so where and how? I think it should just throw a syntax error, this isn't covered as an ability in the man page. I doubt anyone is honestly using this that isn't smart enough to just figure out it isn't supported. Joshua D. Drake ---(end of broadcast)--- TIP 1: 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
