Without checking the sources, but merely from memory, I recall that the
problem at heart is/was that procmail maintains (has to maintain) a
"taintedness" of the DEFAULT variable. Meaning that if procmail notices
that DEFAULT has not been touched, that it assumes that it could still
point to the system mail directory, and that if that is the case, that
that is the *only* situation in which procmail might have to make use of
its special sgid-mail privileges.
Once DEFAULT has been assigned to, procmail gladly relinquishes sgid
rights since "they cannot be important anymore".
DEFAULT is meant to be set by anyone changing it to point anywhere else
*but* the system maildir. DEFAULT is not intended to be set equal to a
spot which will point it right back the same or a different system
maildir. The rationale was that if you are the system administrator,
you should have recompiled procmail with the proper system spool dir
instead of reassigning DEFAULT. Reassigning DEFAULT is a sign of an
unpriviliged user trying to divert mail to a place *other* than the
system maildir.
With respect to procmail figuring out if /var/mail is a symlink to
/var/spool/mail: In general, trying to find out where symlinks point and
act accordingly is a racy business, so trying to be clever about
symlinks and where they point to is logic that is avoided. That does
not mean to say that supporting that is impossible, it's just something
that if it is done, it needs to be implemented very diligently.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
