On 2019-06-28 12:02:30 -0500, Derek Martin wrote: > On Fri, Jun 28, 2019 at 11:08:06AM +0200, Vincent Lefevre wrote: > > On 2019-06-26 14:36:01 -0500, Derek Martin wrote: > > > On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote: > > > > On 2019-06-25 14:26:16 -0500, Derek Martin wrote: > > > > > In some cases it might get cleaned up, but you can just have your > > > > > .profile (or whatever) recreate it when you log in... FWIW this is > > > > > probably what I would do in that case. > > > > > > > > But if the directory has already been created by someone else, > > > > this is not OK. The solution must be compatible with Mutt's > > > > $tmpdir variable (which will not affect other applications, > > > > contrary to $TMPDIR). > > > > > > Well, /tmp exists and was not created by you... ;-) > > > > That's OK for /tmp, but not if I use, for instance > > > > set tmpdir=/var/tmp/$USER > > I think you missed my point. How does Mutt KNOW /tmp is OK? What if > it is not on your system?
/tmp is standard and assumed to be usable (see POSIX, Chapter 10). A system without /tmp is broken. > I gave the example of Windows... which is not POSIX. Windows may need some changes in the Mutt source (not just concerning /tmp). > > because some random user could have created /var/tmp/$USER first > > (note: I want something under /var/tmp for Mutt, but the usual > > temporary directory under /tmp, hence the use of Mutt's $tmpdir > > variable). > > This isn't a problem, except that you need to decide what to do when > it happens. In such a case your mkdir will fail, and you will have to > resort to some back-up plan. which is why I use /var/tmp. It's guaranteed to work. > > > FWIW, I was speaking about $TMPDIR specifically, and generically (i.e. > > > not specific to Mutt, though inclusive of Mutt). If you set $TMPDIR, > > > you don't need to set $tmpdir, > > > > That's not true: one may want a different location for Mutt. A reason > > can be that one generally wants the usual temporary directory under > > /tmp because it is cleaned up on reboot (if decided by the admin), > > Why? As you point out, /tmp is cleaned up only on reboot. That's the issue with Mutt: if the machine reboots while I'm writing a mail, I don't want to lose the message. > No competent admin will reboot the system on you without giving you > some time to clean up what you're doing Silly remark. Machines get rebooted because of (temporary) power outage (happens quite often) or because they crash (happens quite often too). That's the real world. > > I had reported the bug as grave, but got a response in > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878138#32 > > > > quoting: > > > > "/tmp-related bugs which are rendered non-exploitable by this mechanism > > are not treated as security vulnerabilities. If you use a custom > > Linux kernel you should enable it using a sysctl setting" > > Ah. I think the solution is not especially a good one, particularly > given that it is a system-wide behavior. It makes using symlinks in > collaborative environments more difficult. I don't think that symlinks in /tmp or similar that need to be shared occur in practice, even in collaborative environments. Or do you have an example? But combined with other vulnerabilities, this might increase the risk. For instance, if some vulnerability allows one to *reduce* the permissions of such a directory, symlink attacks could become possible again. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
