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



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to