Bug 1848283 - Tainted filename for search [...] in 4.94-1.el7
Summary: Tainted filename for search [...] in 4.94-1.el7
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: exim
Version: epel7
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-18 07:23 UTC by tnowak
Modified: 2020-08-02 21:55 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description tnowak 2020-06-18 07:23:38 UTC
After upgrade from 4.93.3-el7 to 4.94-1.el7 mail server stopped receiving mail.

paniclog:

2020-06-18 05:14:11 Tainted filename for search: '/etc/mail/virtual_domains/domain1.com'
2020-06-18 05:14:11 Tainted filename for search: '/etc/mail/virtual_domains/domain2.com'
2020-06-18 05:14:11 Tainted filename for search: '/etc/mail/virtual_domains/domain3.com'
2020-06-18 05:14:11 Tainted filename for search: '/etc/mail/virtual_domains/domain4.com'

mainlog:

[...] temporarily rejected RCPT <email@domain1.com>: failed to expand "${lookup{$local_part}lsearch*{/etc/mail/virtual_domains/$domain}}": NULL
[...] temporarily rejected RCPT <email@domain2.com>: failed to expand "${lookup{$local_part}lsearch*{/etc/mail/virtual_domains/$domain}}": NULL
[...] temporarily rejected RCPT <email@domain3.com>: failed to expand "${lookup{$local_part}lsearch*{/etc/mail/virtual_domains/$domain}}": NULL
[...] temporarily rejected RCPT <email@domain4.com>: failed to expand "${lookup{$local_part}lsearch*{/etc/mail/virtual_domains/$domain}}": NULL


Nightmare. I had to rollback to 4.93.3-el7 to make it work again.

Comment 2 Marcel Haerry 2020-06-18 21:48:29 UTC
This is also affecting the way how exim-greylist is setting up greylisting:

Tainted filename for search: '/var/spool/exim/db/greylist.db'

After upgrade to 4.94 the standard exim-greylist config gives the following error:

Jun 18 21:50:14 bla exim[20574]: 2020-06-18 21:50:14 1jm0YA-0005Lq-8R Tainted filename for search: '/var/spool/exim/db/greylist.db'
Jun 18 21:50:14 bla exim[20574]: 2020-06-18 21:50:14 1jm0YA-0005Lq-8R H=example.com [1.2.3.4] F=<sender@example.com> temporarily rejected after DATA: failed to expand ACL string "${lookup sqlite {/var/spool/exim/db/greylist.db SELECT host from resenders WHERE helo='${quote_sqlite:$sender_helo_name}' AND host='$sender_host_address';} {1}}": NULL


Exim changed in 4.94 how sqlite should specify the name:


https://git.exim.org/exim.git/commitdiff/b8514d1960e259d49ab2c84c89eba52ab993da3f 
+ 8. Sqlite lookups accept a "file=<path>" option to specify a per-operation
+    db file, replacing the previous prefix to the SQL string (which had
+    issues when the SQL used tainted values).

https://exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html#SECTsqlite

" The preferred way of specifying the file is by using the sqlite_dbfile option, set to an absolute path. "

sqlite_dbfile = /some/thing/sqlitedb
...
${lookup sqlite {select name from aliases where id='userx';}}


https://lists.exim.org/lurker/message/20200605.233950.2daa08d7.en.html#exim-users

BUT this means, that:

* GREYDB needs to be moved out from the included file to main config file, as sqlite_dbfile can't be specified within the acl part
* the exim-greylist.conf.inc should not reference GREYDB at all anymore.

First I thought about submitted a dedicated bug, as the greylist is more specific to a supplied config of the package, while the original bug report here is rather something that needs to be changed in the config. BUT then I thought, this might get various other reports and you might want to have the different solutions more centrally visible.

Comment 3 Russell Odom 2020-08-02 11:07:29 UTC
I see the same issue with greylisting as comment 2 in Fedora - 4.94-1.fc31 - and also had to roll back. Does this need a separate bug for Fedora, or can it be dealt with here?

Comment 4 Florian Bezdeka 2020-08-02 14:51:42 UTC
>https://git.exim.org/exim.git/commitdiff/b8514d1960e259d49ab2c84c89eba52ab993da3f 
>+ 8. Sqlite lookups accept a "file=<path>" option to specify a per-operation
>+    db file, replacing the previous prefix to the SQL string (which had
>+    issues when the SQL used tainted values).

Note: This is part of exim 4.95 (see upstream changelog) only.

Updating to 4.95 should re-enable the current grey-logging configuration, with still minor modifications necessary:

As mentioned above the sqlite lookup now accepts "options".
So all sqlite lookups have to be rewritten / updated.

Example:

Old:
  accept condition = ${lookup sqlite {GREYDB SELECT host from resenders \
                               WHERE helo='${quote_sqlite:$sender_helo_name}' \
                               AND host='$sender_host_address';} {1}}

New:
  accept condition = ${lookup sqlite,file=GREYDB {SELECT host from resenders \
                               WHERE helo='${quote_sqlite:$sender_helo_name}' \
                               AND host='$sender_host_address';} {1}}

Package-Maintainers: 
Any chance to get the 4.95 upstream release into the package repos?

Comment 5 Florian Bezdeka 2020-08-02 15:04:51 UTC
While reading the git changelog for the exim package I just noticed this [1] commit.

The greylogging acl was modified and it requires "sqlite_dbfile" to be set in the main configuration file.
Please make sure that all operators are notified to this required change.

[1] https://src.fedoraproject.org/rpms/exim/c/b707c4f2cb6d2258c89fb4f45a9f4a236951e348?branch=master

I would still prefer the upgrade to 4.95 and updating the greylogging acl as already mentioned.
(Using the file= option)

Comment 6 Florian Bezdeka 2020-08-02 21:55:55 UTC
I just opened a pull request for backporting the necessary fixes from 4.95 at [1].

Let's see what the maintainers say...

[1] https://src.fedoraproject.org/rpms/exim/pull-request/8


Note You need to log in before you can comment on or make changes to this bug.