Roderick Schertler <roderick(_at_)argon(_dot_)org> writes:
I'm unable to combine -m mode, INCLUDERC, and a forking {} block. It
seems that after the cloned {} is entered procmail re-opens all the
nested rcfiles that it's processing. This fails with -m mode here
because the system's chown() isn't restricted so procmail requires that
/etc/procmailrcs be owned by root and mode 700. So, procmail logs a
'Lost "/etc/procmailrcs/test"' message and bails.
Why oh why is /etc/procmailrcs required to be mode 700, rather than
requiring that it isn't writable by group or other?
Because otherwise placing an rcfile in /etc/procmailrcs/ owned by a
non-root user would effectively give that user root privileges: they
could just edit it to create a suid shell, then chown it to root.
/etc/procmailrcs/ could not be safely used untrusted users.
(One also wonders why procmail needs to re-open all the nested include
files (both rather than saving the original FD, and in the face of tail
recursion).)
When a process forks, the shared file descriptors share file positions,
so that the child processes reading of the rcfile would advance the
parent's position in the file. The is no system call to 'unshare' file
positions except by closing and reopening the original file.
The next version of procmail (don't ask me when) will include a new
variable SWITCHRC that closes the the current rcfile. This will allow
a workaround for this situation, but the _real_ solution is to restrict
chown. File giveaways are just a Bad Idea.
Philip Guenther