Re: [exim] Exim 4.94.0.4 works where Exim 4.94 fails with ta…

On 07/11/2020 20:54, Jeremy Harris via Exim-users wrote:
> On 07/11/2020 20:43, Mike Tubby via Exim-users wrote:
>> What do I need to know to fix this one?
>
> Either
> - read back through exim-users, which has amply covered tainting
> or
> - start by hauling up the concept index in the docs, and search on
>    the string "taint.   Then , if that doesn't answer your issue,
>    haul the docs sourcefile "spec.xfpt" from git master into an
>    editor and do the same (it has been enhanced since the 4.94
>    release).
>

Ok, have had a 5 minute scan read ... seems that tainted data is a
{potential} problem, but in my case the variables that I use to build a
path in transport 'local_delivery':

local_delivery:
        driver = appendfile
        maildir_format = true
        directory = /srv/mail/$domain/$local_part/Maildir
        create_directory = true
        directory_mode = 0770
        mode_fail_narrower = false
        message_prefix =
        message_suffix =
        delivery_date_add
        envelope_to_add
        return_path_add
        user = mail
        group = mail
        mode = 0660

have already been used as keys in a database look-up previously in the
router that cause the transport to be called:

local_delivery:
        driver = accept
        condition = ${lookup mysql{SELECT
CONCAT(users.username,'@',domains.domain) AS email FROM \
                users LEFT JOIN domains ON users.domain_id=domains.id
WHERE \
                users.username='${quote_mysql:$local_part}' AND \
                domains.domain='${quote_mysql:$domain}' AND \
                users.active=1 AND \
                domains.active=1}{yes}{no}}
        transport = local_delivery
        user = mail
        group = mail

and have already been sanitised (by accessing a match on the database).

We cannot expect Exim's business logic to know this.

I know that I could write some convoluted SQL to return an untainted
version of the fields but I might as well write:

MariaDB [(none)]> select "Foo" as foo;
+-----+
| foo |
+-----+
| Foo |
+-----+

at this point and just loopback variables through a database connection
so that Exim believes that they are untainted?

Can we have, instead, a directive that allows us to assert 'untainted'
over one or more variables:

    asset_untainted = [ $domain : $local_part ]

or:

    untaint = [ $domain : $local_part ]

or similar, to tell Exim that we know what we are doing using some of
these variables?

Basically 'tainted as default' unless you turn it back off ...?


Mike