https://bugs.exim.org/show_bug.cgi?id=2751
Bug ID: 2751
Summary: include_directory option nonworking, never allows
access
Product: Exim
Version: 4.94
Hardware: x86
URL: https://bugs.debian.org/988301
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Routing
Assignee: unallocated@???
Reporter: eximusers@???
CC: exim-dev@???
Hello,
once I add
include_directory = /etc/exim4
to the system_aliases redirect router
this setting in /etc/aliases
priprema: :include:/etc/exim4/dynaliases/priprema
(with /etc/exim4/dynaliases/priprema simply containing "somewhere@???")
stopped working.
Without include_directory:
root@argenau:~# /usr/sbin/exim4 -bt priprema
R: system_aliases for priprema@???
R: smarthost for somewhere@???
[...]
with include_directory:
root@argenau:~# /usr/sbin/exim4 -bt priprema
R: system_aliases for priprema@???
priprema@??? cannot be resolved at this time: error in redirect
data: failed to open /etc/exim4/dynaliases/priprema (component of included
file); could be symbolic link
There is no permission issue, it is all regular world-readable files and
directories.
This was reported by Josip Rodin in the Debian BTS on upgrading from 4.84 to
4.89. I can reproduce with 4.92.2.
---------------------------
Version: 4.89-2+deb9u8
Hi,
After an upgrade to stretch, and likewise buster, the :include:
functionality of the redirect router seems to be broken.
I have include_directory set to /etc/exim4, and a subdirectory with
files containing alias content, an an aliases file containing e.g.:
priprema: :include:/etc/exim4/dynaliases/priprema
This worked perfectly up to jessie, but after the upgrade, deliveries
started choking with messages like:
R=aliases defer (-17): error in redirect data: failed to open
/etc/exim4/dynaliases/priprema (component of included file); could
be symbolic link
strace shows:
openat(AT_FDCWD, "/etc/exim4/dynaliases", O_RDONLY|O_LARGEFILE) = 7
openat(7, "/priprema", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = -1 ENOENT (No such
+file or directory)
Obviously it's supposed to continue to find the file in that directory,
because the file hasn't been touched...
Am I missing something here?
A diff between 4.84 and 4.89 sources shows that this code was changed
inbetween, with a block of new code using EXIM_HAVE_OPENAT replacing
the old logic...?
---------------------------
--
You are receiving this mail because:
You are on the CC list for the bug.
