<<< Date Index >>>     <<< Thread Index >>>

Re: [Mutt] #3236: mutt: should use /var/tmp for mail drafts by



On Wed, Jun 03, 2009 at 08:50:50AM -0000, Mutt wrote:
> Comment(by vinc17):
> 
>  I agree with madduck.
>  [http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES FHS] even
>  recommends: ''Although data stored in /tmp may be deleted in a site-
>  specific manner, it is recommended that files and directories located in
>  /tmp be deleted whenever the system is booted.''

That sounds an awful lot like a recommendation to me, not a
requirement.  So, a distribution which chooses not to behave this way
is still compliant.  I believe there still are Linux distributions
in somewhat widespread use today which do not behave this way, though
I'm not at liberty at the moment to make a survey to determine that
with any certainty.  So yes, as you have just pointed out, the
cleaning policy of /tmp IS a distribution-dependent behavior.  Thank
you.

>  A system reboot can occur almost at any time, for various reasons. And it
>  generally occurs much more often than disk failures.  

So?  Unless I'm mistaken, a message that's in $tmpdir is one that the
user is *actively* editing (or at least one which Mutt thinks is being
edited), or else it would be moved to postponed.  If the system goes
down *FOR ANY REASON* while the user is in the middle of editing the
message, data loss is at least somewhat likely, regardless of where
you put it.  How likely exactly depends on the situation.  Probably
more likely than a user leaving a message unpostponed when a
non-system-failure downtime is about to occur...

> So, the fact that disk failures can occur is not a reason not to
> change /tmp to /var/tmp (or the user's home directory). 

You're right, it's not a reason not to change it.  However it is a
reason that changing it may be largely pointless.  The other reasons I
gave (e.g.  potentially breaking Mutt on non-Linux systems) are
reasons not to change it.

>  Concerning the possible problems with the user's home directory, this is
>  completely ridiculous: 

Vincent, YOU are completely ridiculous.  Calling someone else's
comments "completely ridiculous" is generally crass and rude, and you
do this somewhat regularly.  My comments are not ridiculous, they are
in fact quite accurate, which makes you not just rude, but rude and
wrong.  That's nearly the definition of ridiculous.  The problems I
described are real, even if they do not impact you personally.  I have
personally managed systems where the security issues I outlined were a
real concern -- when such issues were pointed out to certain users
(and managers) using those systems, they became rather uncomfortable
and wanted to know how to fix it.  Stop being so damned narrow-minded,
and once and for all accept the fact that use cases exist that don't
apply to you.

I would not bother to reply to your comments at all, except that most
of the time you *sound* intelligent, so people might get the mistaken
idea that you know what you're talking about in this case.  You do
not.

> Mutt ''already'' uses the home directory by default for postponed
> messages. 

Just because a behavior exists does not make it the right behavior.

> So, there would ''not'' be more problems, and AFAIK, no-one has
> complained.

That also doesn't mean it's the right thing.  However there would in
fact be more problems... it's just that virtually no one (especially
those who have no experience managing systems for a large number of
users, and/or no security training, formal or informal) is aware of or
understands the problems.  That goes for most software developers,
frankly.  It's also that the severity of the problems varies widely
based upon your usage needs and environment.

Postponed messages are not at all the same thing, because:

 - they exist in a mail folder which is essentially unique to Mutt
 - Mutt is NEVER actively editing them while they are there
 - As a mail folder, postponed can be a maildir, if the user cares
 - As a result, file locking is not an issue

Temp files, by contrast, are (AFAIK) currently always single files,
always at least potentially in an active state of being modified (as
far as Mutt is concerned), and as such are always subject to locking
issues.  This is only likely to be an issue if a user tries to edit
the file in more than one editor session, or do funky things to
modify the temp files directly via external programs, but I've known
people to do such things (even if you do not)...

However, even with regard to postponed messages, security issues
exist.  If the message is sensitive, and intended to be encrypted,
then leaving it postponed WILL EXPOSE SENSITIVE DATA.  Now, hopefully
a user who is security-concious enough to use encryption with e-mail
is also aware enough to avoid postponing sensitive e-mail, though it's
likely people will forget.  

This behavior too is configurable though, by setting the $postponed
variable.  If the user does not want their postponed messages exposed,
they can set it to save them wherever they want, e.g. on local storage
in a protected directory, or in a directory on a thumb drive if that's
more secure.  For many users, who probably use Mutt on their own
workstations with their home directory on their local disk, or on a
home NFS server they control themselves, using $HOME is fine.  If they
never send out sensitive messages, it doesn't matter in the slightest.
But I assure you, there are very real circumstances when it matters a
lot.

Were it not for the fact that this is possible, and that I know how to
configure Mutt to make temp files and postponed messages secure, be
assured that I would have complained very loudly about this long, long
ago.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

Attachment: pgpTxnBrt8FZA.pgp
Description: PGP signature