it doesn't matter if they can really have spaces, it matters if a user who
thinks they could have spaces tries that. The goal is that the module
does not fail in a bizzare way in that case, but with a useful error
message from the correct place.
if modules are run live from the web, an unquoted variable could include
something like table="dbf; run_evil_command; #", and without quoting
they have all the shell access they want. (well, I'm not totally sure
about that, but it scares me enough to be pedantic about it for shell
scripts)
Hamish
ps- "${var}" is a little overkill, I think "$var" is fine. and I'm not
sure if "" around VAR=`` is needed, or if that causes problems if interior
command also contains "". ??
it doesn't matter if they can really have spaces, it matters if a user who
thinks they could have spaces tries that. The goal is that the module
does not fail in a bizzare way in that case, but with a useful error
message from the correct place.
But the user does not define table name in v.db.renamecol. The module takes the table linked to a map.
if modules are run live from the web, an unquoted variable could include
something like table="dbf; run_evil_command; #", and without quoting
they have all the shell access they want. (well, I'm not totally sure
about that, but it scares me enough to be pedantic about it for shell
scripts)
Don't know if a combination of v.db.connect -o with evil table name followed by v.db.renamecol could cause trouble like that.
ps- "${var}" is a little overkill, I think "$var" is fine. and I'm not
sure if "" around VAR=`` is needed, or if that causes problems if interior
command also contains "". ??
I'll leave this to the specialists. There's tons of examples of that usage of quotes in the scripts...
I'll just do as I'm told
it doesn't matter if they can really have spaces, it matters if a user who
thinks they could have spaces tries that. The goal is that the module
does not fail in a bizzare way in that case, but with a useful error
message from the correct place.
if modules are run live from the web, an unquoted variable could include
something like table="dbf; run_evil_command; #", and without quoting
they have all the shell access they want. (well, I'm not totally sure
about that, but it scares me enough to be pedantic about it for shell
scripts)
If modules are run live from the web, there are plenty of other
problems to worry about (buffer overflows, system(), etc).
A web interface would need to validate all input using a "default-deny"
approach, i.e. define what consitutes "valid" input and reject
everything else.
