471,349 Members | 1,534 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,349 software developers and data experts.

SafeConfigParser can set unsafe values

SafeConfigParser 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=ConfigParser.SafeConfigParser()
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._interpolate(section, option, value, d)
File "/usr/lib/python2.5/ConfigParser.py", line 593, in _interpolate
self._interpolate_some(option, L, rawval, section, vars, 1)
File "/usr/lib/python2.5/ConfigParser.py", line 634, in _interpolate_some
"'%%' must be followed by '%%' or '(', found: %r" % (rest,))
ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or
'(', found: '%there'
ConfigParser does not do this:
>>y=ConfigParser.ConfigParser()
y.add_section('test')
y.set('test', 'a', 'hi%there')
y.get('test', 'a')
'hi%there'
Should SafeConfigParser.set() be escaping automatically?

Hamish
Jul 10 '07 #1
4 3716
Should SafeConfigParser.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

Jul 10 '07 #2
En Tue, 10 Jul 2007 20:53:51 -0300, Matimus <mc******@gmail.comescribió:
>Should SafeConfigParser.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 SafeConfigParser.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

Jul 11 '07 #3
Matimus wrote:
>Should SafeConfigParser.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
Jul 11 '07 #4
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:

Expand|Select|Wrap|Line Numbers
  1. from ConfigParser import *
  2. import sys
  3.  
  4. cp = SafeConfigParser()
  5. cp.add_section("sect")
  6. cp.set("sect","opt","hello%world")
  7.  
  8. cp.write(sys.stdout)
  9.  
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.

Jul 11 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Jon Milner | last post: by
2 posts views Thread by James Dean | last post: by
reply views Thread by Robert Rae | last post: by
reply views Thread by Robert Rae | last post: by
7 posts views Thread by TomHL | last post: by
3 posts views Thread by TomHL | last post: by
reply views Thread by Robert Rae | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.