On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote: > On 2019-06-25 14:26:16 -0500, Derek Martin wrote: > > On Tue, Jun 25, 2019 at 09:11:22PM +0200, Vincent Lefevre wrote: > > > On 2019-06-24 17:18:27 -0500, Derek Martin wrote: > > > > Mutt honors $TMPDIR. You should set it. You should probably not use > > > > /tmp, especially on a multi-user system, especially if you care about > > > > security (privacy to be more precise, but that's part of security). > > > > You should probably also not put it on NFS. > > > > > > On the multi-user machines I use, my home is under NFS. So, there > > > isn't much choice. The other directories I can use are just like > > > /tmp. > > > > BUT... you still can do better than just using /tmp. You can create, > > say, /tmp/vincent, with 700 perms, which effectively solves most of the > > problem. Then set TMPDIR to that. :) > > Mutt should do the creation of the intermediate directory for me.
I'm not so sure about that... perhaps if it is doing so due to Mutt's own tmpdir var, but I'm less convinced it should try to make $TMPDIR (which Mutt also honors, though I don't recall the order of precedence). I imagine what it should do instead is, in either case, report that the directory is missing (or unwritable, or whatever) and prompt the user what to do about it. > > 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... ;-) 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, and you should get behavior that is intuitive and reasonable across all your applications that need scratch 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. 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, possibly depending on some arbitrary notion of how persistent the files should be. I think I somewhat recently even saw a third path used... And then there's Windows, which has its own, which IIRC is either %TMP% or %TEMP% (or both), and which the user can arbitrarily change on a system-wide basis (does Mutt deal with this?). Likewise, on a Unix-like system, your local admin might want to use something different entirely, out of paranoia (though, good luck with that--I'm sure tons of things hard-code /tmp). 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. > > You could still use your home directory too... most of the trouble is > > that you have to trust your sysadmins. > > If there's a security issue there, then there's nothing one can do: > my account could be hacked and everything could be read. Sure but obviously it very much depends on the nature of the security issue. NFS has had its own over the years, and due to the distributed, networked nature of NFS, it has most, if not all the same attack vectors that a local disk directory has, plus additional ones. Security is rarely about making your data impenetrable, but rather about mitigating risks. It's hard to argue NFS is less risky than local disk. > The problem is more the reliability of NFS. So temporary files are > better put somewhere else. That too. Privacy is crucial, but availability is job #1 of data assurance (security). > > The other reason to avoid using /tmp (or another world-writable > > directory) is avoiding things like symlink attacks, and similar > > classes of things. > > 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. -- 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.
pgpr089iHA_L3.pgp
Description: PGP signature
