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