[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#648271: [debian-policy] 11.8.3 "Packages providing a terminal emulator" says xterm passes -e option straight to exec



Thomas Koch <thomas@koch.ro> writes:

> I maintain termit. My opinion is, that the policy should rather ask for
> sane behaviour and the proposed change does not look sane.

> Could you please also ammend this topic with a few test cases to make
> testing our terminal emulators easier and to be sure that we're all
> talking about the same subject?

> e.g.

> T=x-terminal-emulator

> 1. $T -e bc       # runs bc as normal
> 2. $T -e "bc --quiet"    # fails?
> 3. $T -e bc --quiet      # runs bc in quiet mode?
> 4. $T -e "bc *"   # * is not expanded since there's no shell started?
> 5. $T -e bc *    # Is * expanded? By whom?

Hi Thomas,

The goal of this change is two-fold.  First, it's to expand the existing
Policy dictate, which says that anything providing x-terminal-emulator
must behave "in the manner that xterm does," but xterm's behavior is
somewhat complex and has also has changed.  So this dictate is not clear
and needs to be made clear.

Second, it's to explicitly state that the behavior of running the command
through the shell if there is only one argument and it doesn't exist as an
executable is allowed but not required.

The reason for the original requirement is that it's nice to be able to
pass arguments with shell metacharacters to programs run inside an
x-terminal-emulator (and indeed may be required for security in some
cases).  We therefore do not want x-terminal-emulator to be gratuitously
passing things to the shell.  Generally, shell expansion will be done by
the caller.

It's important here to distinguish between the behavior of
x-terminal-emulator and the command line.  So, for example, in your
examples above, the behavior will of course change considerably based on
whether those commands are typed into a shell (or passed to system() or
some equivalent) or if they're passed through exec.  To be very clear,
I'll rewrite your questions to specify exec in pseudo-code.

The goal is the following behavior:

    exec($T, "-e", "bc")              --> runs bc
    exec($T, "-e", "bc --quiet")      --> fails OR runs bc --quiet [1]
    exec($T, "-e", "bc", "--quiet")   --> runs bc --quiet
    exec($T, "-e", "bc *")            --> fails OR runs bc * (wildcard) [1]
    exec($T, "-e", "bc", "*")         --> runs bc * (literal)

[1] Programs are allowed to pass the entire argument to -e to the shell
    if and only if there is only one argument and exec fails.

In the last case, "*" is guaranteed to never be expanded.  If the caller
wants shell expansion of the wildcard, it must explicitly run the command
through the shell.  In other words, instead run:

    exec("/bin/sh", "-c", "$T -e bc *")

To see why this is important, consider the following:

    exec($T, "-e", "vi", "some file")

One must be guaranteed that x-terminal-emulator will not pass the second
argument through the shell, since then one would end up editing two files,
one named "some" and one named "file", and it would require elaborate and
tricky quoting to achieve the desired goal.

Does this all make more sense now?  Do you still think the behavior that
Policy is trying to mandate isn't sane?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: