SafeConfigParser can set unsafe values

[Hamish Moffatt]

SafeConfigParse r is supposed to be safer than ConfigParser, but calling
set with a string value containing '%' generates exceptions when you
get() it back.

Python 2.5.1 (r251:54863, Apr 25 2007, 21:31:46)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

>>import configparser

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named configparser

>>import ConfigParser
>>>
>>x=ConfigParse r.SafeConfigPar ser()
>>x.add_section ('test')
>>x.set('test ', 'a', 'hi%there')
>>x.get('test ', 'a')

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/ConfigParser.py ", line 525, in get
return self._interpola te(section, option, value, d)
File "/usr/lib/python2.5/ConfigParser.py ", line 593, in _interpolate
self._interpola te_some(option, L, rawval, section, vars, 1)
File "/usr/lib/python2.5/ConfigParser.py ", line 634, in _interpolate_so me
"'%%' must be followed by '%%' or '(', found: %r" % (rest,))
ConfigParser.In terpolationSynt axError: '%' must be followed by '%' or
'(', found: '%there'


ConfigParser does not do this:

>>y=ConfigParse r.ConfigParser( )
>>y.add_section ('test')
>>y.set('test ', 'a', 'hi%there')
>>y.get('test ', 'a')

'hi%there'


Should SafeConfigParse r.set() be escaping automatically?

Hamish

[Matimus]

Re: SafeConfigParse r can set unsafe values

Should SafeConfigParse r.set() be escaping automatically?

It seems like that would be a nice feature. However, may I offer up
that if you are setting an option and then later on getting that value
back in the same program, you probably should have used some other
storage mechanism in the first place. That is, you shouldn't store
values needed during the runtime of your program in a ConfigParser
instance.

As far as I can tell, these are the valid use cases for ConfigParser:

1. Use ConfigParser to read values from an config file
- This implies .read() followed by .get()s
2. Use ConfigParser to create and write a config file
- This implies .set()s followed by .write()
3. Use ConfigParser to read, modify and write a config file.
- This implies .read() followed by .get()s followed by .set()s
followed by .write()

None of the above use cases involve calling .get() after a .set().
Perhaps I am missing a use case though.

While I think you have technically pointed out a potential bug, I'm
not sure why it matters. Such a bug only comes about for (IMHO) flawed
use cases.

Matt

[Gabriel Genellina]

Re: SafeConfigParse r can set unsafe values

En Tue, 10 Jul 2007 20:53:51 -0300, Matimus <mccredie@gmail .comescribió:

>Should SafeConfigParse r.set() be escaping automatically?

>
It seems like that would be a nice feature. However, may I offer up
that if you are setting an option and then later on getting that value
back in the same program, you probably should have used some other
storage mechanism in the first place. That is, you shouldn't store
values needed during the runtime of your program in a ConfigParser
instance.
>
As far as I can tell, these are the valid use cases for ConfigParser:
>
1. Use ConfigParser to read values from an config file
- This implies .read() followed by .get()s
2. Use ConfigParser to create and write a config file
- This implies .set()s followed by .write()
3. Use ConfigParser to read, modify and write a config file.
- This implies .read() followed by .get()s followed by .set()s
followed by .write()
>
None of the above use cases involve calling .get() after a .set().
Perhaps I am missing a use case though.
>
While I think you have technically pointed out a potential bug, I'm
not sure why it matters. Such a bug only comes about for (IMHO) flawed
use cases.

This not only happens when get() after a set(), but with all the use cases
above. An intervening write()/read() does not change things.
But I'm not sure it is a bug really. If all % were escaped automatically,
there is no way to write a templatized value. Maybe SafeConfigParse r.set
should grow an escape argument, controlling whether one wants the value
escaped or not. For compatibility reasons should default to False, for
usability reasons should default to True.

--
Gabriel Genellina

[Hamish Moffatt]

Re: SafeConfigParse r can set unsafe values

Matimus wrote:

>Should SafeConfigParse r.set() be escaping automatically?

>
It seems like that would be a nice feature. However, may I offer up
that if you are setting an option and then later on getting that value
back in the same program, you probably should have used some other
storage mechanism in the first place. That is, you shouldn't store
values needed during the runtime of your program in a ConfigParser
instance.

I agree, but that was a trivial example to demonstrate the problem.
Writing the file out to disk writes it exactly as set(), causing a get()
to fail just the same later.

While I think you have technically pointed out a potential bug, I'm
not sure why it matters. Such a bug only comes about for (IMHO) flawed
use cases.

Sorry, that's incorrect.


Hamish

[Matimus]

Re: SafeConfigParse r can set unsafe values

I agree, but that was a trivial example to demonstrate the problem.

Writing the file out to disk writes it exactly as set(), causing a get()
to fail just the same later.

No... The above statement is not true.

The following code:

from ConfigParser import *
import sys

cp = SafeConfigParser()
cp.add_section("sect")
cp.set("sect","opt","hello%world")

cp.write(sys.stdout)

Produces this output:
[sect]
opt = hello%world

The write method never calls get. However, when you read the file that
was output by the above code using .get(...) will raise an error. You
can avoid that error by setting the optional 'raw' parameter to True.