"Charles Hines" <chuck_hines(_at_)vnet(_dot_)IBM(_dot_)COM> writes:
"Philip" == Philip Guenther <guenther(_at_)gac(_dot_)edu> writes:
Philip> The reason for this is that symlinks break dotlocking: a
Philip> dotlock is a lock on a _name_, and links (hard or soft) give
Philip> the same underlying object two or more names.
Ok, for this I can understand not wanting hard links, but following a
symbolic link through to the actual file (to access & lock via the
actual name) would be less of a problem. Or perhaps dotlock both the
symlink name and the actual file?
This is a solution to the wrong problem: in the configuration process
you've told procmail that your mailspool is 'physically' located at
some location. It is a design decision of procmail that it will make
certain guarantees about the state of your mailbox before it will let
you deliver to it. Those guarantees cause problems when applied to the
wrong location. Give procmail the correct location and all these
problems will disappear.
Besides, isn't dot locking a non-manditory type of lock anyways?
Programs that don't recognize that type of locking could write to the
file regardless, no?
Mandatory file locking is not implemented on all unices, and almost no
one uses it, certainly not mail programs. Not being able to break a
lock, no matter what, is a Bad Thing. So, yes, if a process doesn't
follow the rules of accessing your mailspool, they can corrupt it
and/or get corrupt data. That's always been true. Conventions are
powerful.
...
Philip> In addition following symlinks offers all kinds of security
Philip> holes (readlink() and lstat() cannot be combined into an
Philip> atomic operation).
I'm not sure I see how that could be a security problem, at least not
in this instance. Could you give me an example?
In a particular case it might not be a problem, but procmail doesn't
know that, can't guarantee it, and will all your future sysadmins know
to consider that when changing things in the future? Being secure
means not trusting anything that might change while you're not looking
at it.
But anyways, is there any way for me to stop this behavior via the
.procmailrc or something similiar, or will I have to go in and muck
with the source code to stop this behavior?
Philip> The solution is to tell procmail to use the true filename. If this
Philip> symlinking is for all users, then you should just recompile procmail
Philip> to use the correct algorithim to set ORGMAIL and DEFAULT.
I could recompile it with this new algorithm, as the users in my area
all use the same symlink setup, but a lot of people from other areas
sometimes come to me for tools and they wouldn't be able to use it
then.
Then compile another binary for them. It's not like it takes more than
10 minutes. They should compiling their own anyway so that the
autoconf program can determine which kernel locking strategies work
with their OSes. Procmail needs to know enough about the system that
copying binaries around *should* fail, so that you're forced to
configure it locally.
Philip> You need to set DEFAULT as well as ORGMAIL (procmail first
Philip> tries delivery to $DEFAULT, then to $ORGMAIL).
I actually did try setting both of them, but it still nukes the
symlink since the the /var/spool/mail/$USER is hardcoded and can't be
overridden.
I'm sorry, I forgot that the screening of the system mailbox takes
place at startup, before the .procmailrc is read or command line
assignments are noticed. David Tamkin pointed out that you can get
around this by running procmail as follows:
procmail -m $HOME/.procmailrc
then make sure you assign to ORGMAIL and DEFAULT at the top of your
.procmailrc. Given that you control the procmail binary, I personally
strongly recommend *against* doing this. Henry Spencer is oft quoted,
"If you lie to the compiler, it will get its revenge." Lieing to
procmail like this is just putting off the Evil Day.
(Or to summarize: if you think you know better than procmail, then do
whatever you like. Just don't blame it on procmail when things break.)
Philip Guenther