M Champion:
> Hi Wietse,
>
> >> The DB dump shows :
> >>
> >> londonstransport+bncbdzntlposqirbr426sgamgqeh7mv...@googlegroups.com???
> >> 0:0:1637682515:250 2.1.5 OK s8si901258edx.4 - gsmtp
> > There are 0xc2 0xa0 bytes at the end of the storage key, but not
> > in your query.
>
> Apologies,? I pasted the output generated by 'postmap -s' which puts a
> tab character (9) between key and value. I can't say where the other
> bytes came from. The extra bytes aren't in the key part of database file
> hex dump so still at a loss why postmap -q doesn't match :
>
> 00006860 70 00 34 00 00 00 00 00 45 00 6c 6f 6e 64 6f 6e |p.4.....E.london|
> 00006870 73 74 72 61 6e 73 70 6f 72 74 2b 62 6e 63 42 44 |stransport+bncBD|
> 00006880 5a 4e 54 4c 50 4f 53 51 49 52 42 52 34 32 36 53 |ZNTLPOSQIRBR426S|
> 00006890 47 41 4d 47 51 45 48 37 4d 56 4b 55 41 40 67 6f |GAMGQEH7MVKUA@go|
> 000068a0 6f 67 6c 65 67 72 6f 75 70 73 2e 63 6f 6d 00 30 |oglegroups.com.0|
OK, the storage key is null-terminated. you may have to use a postmap option
to add a null byte to the query.
> > Your postmap queries will have a shell command injection attack
> > of the command is processed by a shell.
> I find your last paragraph worrying. Do you mean my own postmap queries
> will facilitate an external attack? Or that my queries are the attack?
> I really don't want open any security holes.
perl, python etc can invoke commands as a list, or as a string which
is parsed by a shell. The first form is safe, the other not.
WietsE
