Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

[Steffen Nurpmeso]

Derek Martin wrote in <20190624233654.gb13...@bladeshadow.org>:
 |On Tue, Jun 25, 2019 at 12:45:02AM +0200, Steffen Nurpmeso wrote:
 |> Hmm, while i totally support the $TMPDIR environment variable, and
 |> personally dislike it a lot if i set it and someone simply does
 |> not adhere to it, and if its only for testing purposes.., it shall
 |> be remarked that OpenBSD "removed support for $TMPDIR" in the base
 |> system, as far as i know and recall.  Are they young?  Well, yes..
 |
 |I think you must be mistaken, because A) that would be insane, B)
 |would require a lot of pointless work to remove it from many shell
 |utilities (and all of the shells), and C) I see references to it
 |being supported, for example in ssh and ssh-agent, the mktemp man
 |page, the ksh (openbsd's default shell) man page, etc..
 |
 |I did see reference to support for $TMPDIR being removed from crontab
 |("because it's not useful in crontab"), which seems kind of idiotic to
 |me, as well as sendbug and newfs (why would newfs need $TMPDIR anyway?
 |Though it seems useful in sendbug)... but that does not amount to it
 |being removed from the core system.

Well.. i think it was more about it, .. and grepping in the tree
it is true for all the in-base daemons and such, except ssh.
From grepping i see it still being used in tmpname.c of stdio,
which surprised me a bit.  My memory was about a ML thread where
usage of TMPDIR was "loudly" discouraged.

 |That said, none of it matters in the context of Mutt, unless they went
 |out of their way to remove support for it in their port... but even
 |then you can always just get the source.

It would have mattered from what comes in via the operating system
libraries, and tools _possibly_ called from within mutt, but
definetely those called during configuration/build, which is all
i wanted to say.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: meaning of number of lines in the message (%l in index_format)

[Eike Rathke]

Hi,

On Monday, 2019-06-24 18:41:56 -0500, Derek Martin wrote:

> Or just remove it.  If it's not accurate (or even if it is) what value
> can it really provide?

Even if it isn't accurate it gives me a rough idea about the size of the
message (usually after viewed already which calculates the value),
specifically if attachments are involved. It helps when sorting by
message size, which I sometimes used to delete the largest attachments
that aren't of interest (anymore) and only take up disk space.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: meaning of number of lines in the message (%l in index_format)

[Derek Martin]

On Tue, Jun 25, 2019 at 01:27:35PM +0200, Eike Rathke wrote:
> On Monday, 2019-06-24 18:41:56 -0500, Derek Martin wrote:
> > Or just remove it.  If it's not accurate (or even if it is) what value
> > can it really provide?
> 
> Even if it isn't accurate it gives me a rough idea about the size of the
> message (usually after viewed already which calculates the value),

There's already %L for that (size of the message), which should always
be precise, and serve this purpose better.  Just saying...


-- 
Derek D. Martinhttp://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.



pgpSrt9rV0JcL.pgp
Description: PGP signature

Re: meaning of number of lines in the message (%l in index_format)

[Derek Martin]

On Tue, Jun 25, 2019 at 10:33:11AM -0500, Derek Martin wrote:
> On Tue, Jun 25, 2019 at 01:27:35PM +0200, Eike Rathke wrote:
> > On Monday, 2019-06-24 18:41:56 -0500, Derek Martin wrote:
> > > Or just remove it.  If it's not accurate (or even if it is) what value
> > > can it really provide?
> > 
> > Even if it isn't accurate it gives me a rough idea about the size of the
> > message (usually after viewed already which calculates the value),
> 
> There's already %L for that (size of the message), which should always
> be precise, and serve this purpose better.  Just saying...

Sorry, I'm not entirely awake yet.  That's not what %L does... It
shows the size of the currently displayed messages in the index menu.

-- 
Derek D. Martinhttp://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.



pgpZpkCVDXZBx.pgp
Description: PGP signature

Re: meaning of number of lines in the message (%l in index_format)

[Moritz Barsnick]

On Tue, Jun 25, 2019 at 10:45:07 -0500, Derek Martin wrote:
> On Tue, Jun 25, 2019 at 10:33:11AM -0500, Derek Martin wrote:
> > > On Monday, 2019-06-24 18:41:56 -0500, Derek Martin wrote:
> > > > Or just remove it.  If it's not accurate (or even if it is) what value
> > > > can it really provide?
> > >
> > > Even if it isn't accurate it gives me a rough idea about the size of the
> > > message (usually after viewed already which calculates the value),

I agree. OTOH, I have received messages with large one-liner HTML
attachments which obviously seemed small. Or people write plain text
paragraphs without breaking lines ...

> > There's already %L for that (size of the message), which should always
> > be precise, and serve this purpose better.  Just saying...
>
> Sorry, I'm not entirely awake yet.  That's not what %L does... It
> shows the size of the currently displayed messages in the index menu.

%c is what shows the size of the message in the index. The advantage
with %l is that its number of digits is log10, so by the number of
digits, you can quickly glimpse the magnitude of the size. While it's
nice that %c automatically reduces to k/M, it's hard to see the
difference between 1.3k and 1.3M at a quick glimpse across the index.

Cheers,
Moritz

Re: Security: Mutt and mailcap rules

[Vincent Lefevre]

On 2019-06-24 10:13:43 +1000, Cameron Simpson wrote:
> On 23Jun2019 12:36, vincent lefevre  wrote:
> > I'm not sure whether this is a good idea. The temporary directory
> > may be (and often is) world-writable, and on multi-user machines,
> > this increases the risk of vulnerability. For instance, some
> > programs may consider configuration files in the current working
> > directory, and/or may write/re-read files there.
> 
> Ugh. Yes. Have we got some real world examples in mind?

I had discovered two such bugs (or similar):

* A bug in xpdf (typically the kind of program that can be run from
  mailcap), with possible code execution when opening a URL from the
  PDF file:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641941

* With inkscape + .eps argument, inkscape was changing the current
  working directory to /tmp before handling the argument:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654341
(CVE-2012-6076)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: meaning of number of lines in the message (%l in index_format)

[Vincent Lefevre]

On 2019-06-25 19:46:39 +0200, Moritz Barsnick wrote:
> I agree. OTOH, I have received messages with large one-liner HTML
> attachments which obviously seemed small. Or people write plain text
> paragraphs without breaking lines ...

I've noticed that too.

> %c is what shows the size of the message in the index.

Note that the %c value also depends on the encoding, but this may
be less surprising.

> The advantage with %l is that its number of digits is log10, so by
> the number of digits, you can quickly glimpse the magnitude of the
> size. While it's nice that %c automatically reduces to k/M, it's
> hard to see the difference between 1.3k and 1.3M at a quick glimpse
> across the index.

Yes, perhaps the reason I do not use %c. And the fact that the
scaling facteur is on the right instead of the left makes this
even harder (that's a bit like the American dates MMDD).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

[Derek Martin]

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. :)  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.

You could still use your home directory too... most of the trouble is
that you have to trust your sysadmins.  But typically they already
have access to your mail, so... ¯\_(ツ)_/¯  The other issue is if
there are weaknesses in the system that allow privilege escalation, an
attacker can get access to your files, which may be sensitive.  NFS
may (or may not) make that easier, because it can provide additional
attack vectors.  There's root squash of course, but if the user can
get root they can also just setuid() to YOUR user, via whatever means.
The other reason to avoid using /tmp (or another world-writable
directory) is avoiding things like symlink attacks, and similar
classes of things.

It may also be possible, in uncommon cases, to mount a remote file
system that you control (say from a laptop or USB stick or whatever)
and use that.  In most cases involving multi-user systems this
probably won't be possible, but in some circumstances it might be an
option.

-- 
Derek D. Martinhttp://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.



pgpICgAXeH8mN.pgp
Description: PGP signature