Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Vincent Lefevre]

On 2014-05-05 14:03:36 +0900, Charles Plessy wrote:
> given that the appendix A of RFC 1524 is quite clear that commands have been
> run through “/bin/sh -c ”, I propose to close that bug by adding a reference
> to RFC 1524 in the “SEE ALSO” section of mailcap(5) man page.

Thanks for the explanation. Indeed the reference would be useful.

This would mean that applications that handle mailcap files directly
(without using run-mailcap, for which using a wrapper is trivial)
would have to provide some extension.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Charles Plessy]

Le Mon, May 05, 2014 at 02:03:36PM +0900, Charles Plessy a écrit :
> 
> Hello dear Vincent and Jonathan,

Hmmm, that is a typo, sorry for the over-sweetness of the salutation :)

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Charles Plessy]

Control: tag -1 + confirmed
thanks

Le Fri, Jul 22, 2011 at 02:55:45AM +0200, Vincent Lefevre a écrit :
> 
> On 2011-07-21 12:48:17 -0500, Jonathan Nieder wrote:
> > Could you elaborate?  Currently "run-mailcap" only reads $DISPLAY and
> > does not write $XAUTHORITY or any other variable, and that actually
> > seems sensible to me.
> 
> My bug report was about the mailcap(5) man page (which describes
> mailcap files, independently of run-mailcap: run-mailcap is cited
> only in the "SEE ALSO" section), not about run-mailcap itself.
> Mutt uses the mailcap files, but not run-mailcap (though it more
> or less reimplements run-mailcap). The consequences can be very
> similar, though.

Hello dear Vincent and Jonathan,

given that the appendix A of RFC 1524 is quite clear that commands have been
run through “/bin/sh -c ”, I propose to close that bug by adding a reference
to RFC 1524 in the “SEE ALSO” section of mailcap(5) man page.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Vincent Lefevre]

On 2011-07-28 17:50:21 +0200, Jonathan Nieder wrote:
>  c. programs likely to be run through screen could implement some
> specification for modifying the environment when reattached
> or when launching X apps (for example by running a special
> wrapper or linking to some special library).

This is what I do (using wrappers). This works well in practice.
My scripts are available via my Mutt page:

  http://www.vinc17.net/mutt/index.en.html#xscreen

But for instance, Mutt needs to be recompiled with some special
option --with-exec-shell=/path/to/sh.screen to run the /bin/sh
wrapper instead of /bin/sh directly.

> If I understand correctly, this bug is, roughly speaking, about (c).
> The specs in question would be the mailcap spec and the implementation
> of xdg-open.  It wouldn't help with programs that try to run
> x-terminal-emulator without a mailcap file to tell them how, but after
> looking at the alternatives, it does start to look nice by comparison.
> :)

IMHO the spec should be flexible enough to allow clean user
customization. Hardcoding the shell to /bin/sh is a bad idea.

> Cc-ing the screen maintainers in case they know a clean approach we've
> missed.

Concerning screen, it would be great if it supported hooks to allow
things done by my escreen wrapper

  http://www.vinc17.net/unix/xscreen/escreen

in a much cleaner way (my wrapper tries to guess what screen session
will be resumed).

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



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Jonathan Nieder]

Vincent Lefevre wrote:

> The problem is that when Mutt or run-mailcap is run, the value of
> $DISPLAY (and $XAUTHORITY) may be incorrect, and it is unavoidable.
> The reason is that these environment variables are inherited when
> the process is started, and when a new X session is started, the
> values of these variables are no longer valid (they no longer
> reflect the parameters of the X session), and an external process
> can't change their values to correct them.

Yes, this problem rears its head any time a long-lived commandline
utility wants to launch an X application.  If the Wayland developers
get their way, it may apply to some graphical utilities in the future,
too. :)  The fundamental thing is that screen has no way to modify the
environment of attached programs.

All the thorough fixes I can imagine for this are offensively ugly:

 a. screen could ptrace its clients and inject environment variables.
 b. an LD_PRELOAD hack initiated by screen could inject environment
variables at some suitable time (exec, say).
 c. programs likely to be run through screen could implement some
specification for modifying the environment when reattached
or when launching X apps (for example by running a special
wrapper or linking to some special library).
 d. X clients could start interpolating variables in the value of
DISPLAY and XAUTHORITY, to make configurations like
XAUTHORITY='$HOME/.Xauthority' possible.

At first glance, (d) looks unoffensive, but it's kind of hard to
change the X client libs on remote systems.  I don't know what the
right thing to do is.

If I understand correctly, this bug is, roughly speaking, about (c).
The specs in question would be the mailcap spec and the implementation
of xdg-open.  It wouldn't help with programs that try to run
x-terminal-emulator without a mailcap file to tell them how, but after
looking at the alternatives, it does start to look nice by comparison.
:)

Cc-ing the screen maintainers in case they know a clean approach we've
missed.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Vincent Lefevre]

Hi Jonathan,

On 2011-07-21 12:48:17 -0500, Jonathan Nieder wrote:
> Could you elaborate?  Currently "run-mailcap" only reads $DISPLAY and
> does not write $XAUTHORITY or any other variable, and that actually
> seems sensible to me.

My bug report was about the mailcap(5) man page (which describes
mailcap files, independently of run-mailcap: run-mailcap is cited
only in the "SEE ALSO" section), not about run-mailcap itself.
Mutt uses the mailcap files, but not run-mailcap (though it more
or less reimplements run-mailcap). The consequences can be very
similar, though.

The problem is that when Mutt or run-mailcap is run, the value of
$DISPLAY (and $XAUTHORITY) may be incorrect, and it is unavoidable.
The reason is that these environment variables are inherited when
the process is started, and when a new X session is started, the
values of these variables are no longer valid (they no longer
reflect the parameters of the X session), and an external process
can't change their values to correct them.

So, one solution is to do the correction by the shell that will
run the programs specified in the mailcap file. However, if it
specified that the shell is /bin/sh, this is not possible.

> By using system(3), run-mailcap leaves the option open of bypassing
> the shell and using execve(3) directly when no metacharacters appear,

Using execve(3) directly when no metacharacters appear is incorrect
as there may be shell constructs, e.g.

  . /path/to/rcfile && some_command %s

Also, even with a simple command, there may be differences between
/bin/sh and execve if the command is also implemented as a shell
builtin (e.g., "test").

> or compiling mailcap files to bytecode to speed up more complex
> entries.  I don't know if either of those would be a net win; I just
> mention them to explain why I think that _not_ respecting $SHELL is a
> good abstraction.
> 
> It sounds to me like your usecase would be better served by teaching
> run-mailcap to use some hook to update the environment

That's another possibility.

> (but why run-mailcap and not all the other tools that might launch
> an X program, like xdg-open?)

This wouldn't be specific to run-mailcap. I've cited the case of Mutt.
In fact, concerning Mutt, there are other places when one wants to
update the environment (e.g. when it starts an editor to compose a
message). For thi reason, I've recompiled it to run a /bin/sh wrapper
instead of /bin/sh directly. But this also means that it no longer
follows the description in the mailcap(5) man page. That's why the
mailcap(5) man page needs to be less specific about the shell.

> or a more rich mailcap syntax that allows
> ~/.mailcap to override /etc/mailcap in a more complex way.  Or
> something like that --- it's not obvious to me since I don't
> understand the context yet.

In the mailcap files, there could be some command to specify the
shell to use when running a command. ~/.mailcap would have the
precedence as usual, and the shell specified would be used on all
entries, even if they come from a different mailcap file.

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



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Jonathan Nieder]

Hi Vincent,

Vincent Lefevre wrote:

> When the user runs a text program that uses the mailcap system (e.g.
> Mutt) in GNU Screen, it is not possible to run as X11 program via the
> mailcap system after the X11 session has changed, because the value
> of $XAUTHORITY has changed. Using a fixed symlink (in a private
> directory, for more security) to the real X authority file, possibly
> depending only on the screen session, and updated via a screen
> wrapper, might work as a work around, but has some limitations
> (e.g. because several screens could be used on several displays)
> compared to the following suggestion.

Could you elaborate?  Currently "run-mailcap" only reads $DISPLAY and
does not write $XAUTHORITY or any other variable, and that actually
seems sensible to me.

By using system(3), run-mailcap leaves the option open of bypassing
the shell and using execve(3) directly when no metacharacters appear,
or compiling mailcap files to bytecode to speed up more complex
entries.  I don't know if either of those would be a net win; I just
mention them to explain why I think that _not_ respecting $SHELL is a
good abstraction.

It sounds to me like your usecase would be better served by teaching
run-mailcap to use some hook to update the environment (but why
run-mailcap and not all the other tools that might launch an X
program, like xdg-open?) or a more rich mailcap syntax that allows
~/.mailcap to override /etc/mailcap in a more complex way.  Or
something like that --- it's not obvious to me since I don't
understand the context yet.

Thanks for writing, and hope that hellps.
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#634254: mime-support: The mailcap system is incompatible with GNU Screen (should use $SHELL)

[Vincent Lefevre]

Package: mime-support
Version: 3.51-1
Severity: wishlist

When the user runs a text program that uses the mailcap system (e.g.
Mutt) in GNU Screen, it is not possible to run as X11 program via the
mailcap system after the X11 session has changed, because the value
of $XAUTHORITY has changed. Using a fixed symlink (in a private
directory, for more security) to the real X authority file, possibly
depending only on the screen session, and updated via a screen
wrapper, might work as a work around, but has some limitations
(e.g. because several screens could be used on several displays)
compared to the following suggestion.

It should be possible that the program specified in the mailcap
configuration be run by a user-provided shell, typically using
the $SHELL environment variable, without modifying the mailcap
configuration (because this configuration may already be provided
by the system, here Debian). For instance, with zsh, the .zshenv
file is always sourced and could do the necessary to fix the
environment.

Though this is up to the various programs to do that, the mailcap
specification should allow them to do that.

The mailcap(5) man page currently says:

  The "command" field is any UNIX command ("cat %s" in the above
  example), and is used to specify the interpreter for the given
  type of message. It will be passed to the shell via the system(3)
  facility.

but system(3) specifies that /bin/sh -c is used to run the command.

The mailcap(5) man page should say:

  It will be executed either with the user's shell or with the
  system(3) facility.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  file  5.04-5+b1  Determines file type using "magic"

mime-support suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org