Hello.
On Thu, Jun 25, 2020 at 09:16:59PM +0100, Jeremy Harris via Exim-users wrote:
> On 25/06/2020 20:50, Evgeniy Berdnikov via Exim-users wrote:
> > at least in statement "In all other situations, this variable expands
> > to nothing", because it may be filled if no lookup is done.
>
> Yes, that is no longer true. See the sections starting
>
> http://exim.org/exim-html-current/doc/html/spec_html/ch-domain_host_address_and_local_part_lists.html#SECTlistresults
Referenced text have broken record about 'domains' match, I expect some
words about $domain_data variable. Hope you'll supply them.
And I have question about user interface, which becomes very obscure and
inconvenient. All these innovations with tainting bring problems. In some
cases they may be "resolved" by lookups. Obviously, the idea is to restrict
file name patterns to some predefined set of strings, stored somewhere
in database, in hope that this set would be less risky then data from the
wild. Well, it seems good on first glance. But many users want to use
file system as native database with data-driven records, i.e. with
file names constructed from $local_part, $domain, $sender_host and other
variables that can't be predicted. They can't be expressed as a set of
predefined strings. Is there any effective solution for this case?
I can propose awful "untainting" algorithm: 1. construct a tainted
string, 2. put it into database, 3. make lookup to get back "untainted"
data. Any protection against "../" inside, or against SQL injection will
be dropped, but it allows construction of arbitrary untainted strings with
minimum efforts. And I'm sure that samples of such "untainting functions"
became available in internet if Exim's interface continue to evolve in
direction of obscurity and inconveniece.
In my opinion, in order to give an effective tool for data protection,
one should supply simple and copletely "intuitive" interface. For files
it may be a function, say, ${check_file_path:...}, which checks its
argument for dangerous patterns (such as "../") and specials, then returns
untainted copy of string if everything is OK, or throws an exception.
For SQL such function may be ${check_sql_data:...}. Moreover, it seems
better to add such functionality to existing quoting functions:
${qoute_ldap:...}, ${quote_mysql:...}, etc.
Jeremy, I kindly propose to think about movement in this direction.
You have done a really great work, but for the present its result is
too complex and too restrictive for use. If you don't supply simple
and convenient interface, Exim would lose its main advantage, power of
built-in scripting language, and inavitably lose its users. IMHO.
--
Eugene Berdnikov
