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? I gave the example of Windows... it does not use /tmp, though you can create it. Other systems may use some arbitrary thing, for arbitrary reasons. Now what? > 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. > > 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. No competent admin will reboot the system on you without giving you some time to clean up what you're doing--you see the notification, and postpone your message. That does not live in $TMPDIR or $tmpdir. By default that's ~/postponed. If you put it in $TMPDIR you have done something dumb. Nothing else mutt creates in $tmpdir makes much sense to require persistence. That basically leaves attachments and encoding conversions, which are by nature ephemeral. $TMPDIR is fine for those, regardless of whether it is /tmp or /var/tmp. > 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). I think this is mostly balderdash. Small files will mostly take negligible time to read from disk, and those that have been accessed recently should generally be in buffer cache (i.e. RAM) so tmpfs isn't any faster than that. Larger files need space. So basically, don't use tmpfs, ever--it gets you both behaviors automatically as appropriate, unless your system is under memory pressure, in which case you have a different problem. Exceptions with very specific usage patterns surely exist, but the vast majority of users shouldn't notice or care, and those that do can configure the system as appropriate FOR THOSE APPLICATIONS, setting TMPDIR for them in a wrapper script. The "long discussions" are, I would guesstimate, *mostly* people complaining about problems they don't actually have. > 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). Obviously I don't. =8^) > > > 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" 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. In such cases the admin might be inclined to disable it, which renders bugs which "are rendered non-exploitable by this mechanism [and] are not treated as security vulnerabilities" just as vulnerable as they ever were. I could go into some detail about this, though I think we're getting way out of the scope of this thread/list. I might start a thread about it on LKML though if I find myself with a few spare cycles. FWIW many years ago I suggested something similar, but it was for hard links, and it was a mount option. Ted Tso seemed to like the idea, but AFAIK it went nowhere. -- 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.
pgpeo77eM_2kU.pgp
Description: PGP signature
