On Wed, Dec 18, 2024 at 07:42:18PM +0100, Marcin Owsiany via Exim-users wrote:
> However investigating closely I couldn't see any setting that would prevent
> access to the spool directory. And what's more important I couldn't find
> anything that would prevent reading the data file that already have just
> been written to in the same context.
It might be valuable do describe what you did and what got as a result.
Say, did syscall tracing (with strace) and post output for operations
with spool file(s), until error. Probably trace should also include
setuid/setgid/setfsuid and similar syscalls. Note that tracing
of setuid binary is somewhat tricky.
Taking known sequence of syscalls, that lead to an error, one could try
to reproduce it by hands, say, with exim's ${run{..}} and some scripting.
I suspect you have some restrictions for setuid binaries from kernel
modules, such as selinux/apparmor/etc. But it seems good starting point
to compare ownership and permissions of files with working system
that has no such problem.
--
Eugene Berdnikov
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
