[sos-devel] [PATCH] postgresql: avoid to crash with numerical passwords

Bryn M. Reeves bmr at redhat.com
Mon Dec 15 17:50:28 UTC 2014


On Fri, Nov 14, 2014 at 02:22:11PM +0000, Bryn M. Reeves wrote:
> On Fri, Nov 14, 2014 at 02:35:45PM +0100, Sandro Bonazzola wrote:
> > Issue: https://github.com/sosreport/sos/issues/433
> > Change-Id: I99fd0fe913e3f99826f98cb2b8cf7a460ecb5c4c
> > Signed-off-by: Sandro Bonazzola <sbonazzo at redhat.com>
> > ---
> >  sos/plugins/postgresql.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/sos/plugins/postgresql.py b/sos/plugins/postgresql.py
> > index 350131f..0a51074 100644
> > --- a/sos/plugins/postgresql.py
> > +++ b/sos/plugins/postgresql.py
> > @@ -51,7 +51,7 @@ class PostgreSQL(Plugin):
> >          # is no need to save and restore environment variables if the user
> >          # decided to pass the password on the command line.
> >          if self.get_option("password") is not False:
> > -            os.environ["PGPASSWORD"] = self.get_option("password")
> > +            os.environ["PGPASSWORD"] = str(self.get_option("password"))
> 
> This is just working around the problem; the type of the return value
> of get_option() should not depend on the value passed on the command
> line.

Unfortunately it does; the current behaviour is to attempt to convert
each plugin option to an integer (in the global code) and only pass
it along as a string if that fails.

Changing this would mean re-working a lot of plugins that now take
numeric arguments or introducing a type field to the plugin option
tuple (which is already a bit long..). If we do go down that route
it needs to happen after the option_list cleanup (e.g. removing the
fast/slow thing - #274).

So I think at least for now your fix is the correct one; postgresql
knows that it wants to work with strings here and until we have
better plugin option infratructure I think this is the best
solution.

Cheers,
Bryn.




More information about the sos-devel mailing list