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 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). > 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), which is something that one doesn't want for mail that is being written. > and you should get behavior that is intuitive and reasonable across > all your applications that need scratch space. Different applications have different needs: some prefer performance, others need space (see the long discussion(s) after /tmp was switched to the faster tmpfs, but with little space). > If you want Mutt's $tmpdir, you almost certainly also want $TMPDIR, > so unless you've imagined some bizarre, contrived use case where you > want those two paths to be different, setting the former is > redundant. No, I have Mutt's $tmpdir set to /var/tmp, but TMPDIR still unset as I usually want /tmp for applications. > That said: > > If the directory exists and is not owned by you, certainly I can agree > Mutt should not try to use it, if it is not the system's normal /tmp > equivalent. But how do you decide that in a portable way? Some use > /var/tmp now, Which I've done for years. Concerning ownership and permissions, /var/tmp is like /tmp (that's the reason why it is also protected against symlinks attacks). > I think this consideration makes it harder for Mutt to do the right > thing. I suppose it could first check if $tmpdir/$TMPDIR is owned by > the user (and ideally has 700 perms, though no doubt some folks would > complain about that requirement), then check if it's owned by root and > world-writable with the sticky bit set, and finally complain loudly > and ask you what to do. I think that Mutt should have an option to create a random directory under the specified temporary directory ($tmpdir or $TMPDIR or /tmp), and use that as the real temporary directory (some other applications or utilities do that). On exit, if this directory is empty, Mutt should remove it, and perhaps have a quad option if the directory is not empty (I believe that this should be unusual). > > At least symlink attacks are now protected by the kernel (and BTW, a > > bug in some Debian package related to a symlink attack is no longer > > regarded as a security bug by Debian, no longer RC). > > Eh? You have a reference for this? I've not heard of it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878138 "muttprint: still vulnerable to symlink attack (race condition)" 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" (the mechanism is the kernel protection, which is actually optional according to the procfs(5) man page...). -- 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)
