Bug 219532 – x11-terms/xterm resize (or the equivalent escape code) is not able to change window size

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Carlo Marcelo Arenas Belon 2008-04-27 20:46:56 UTC]

problem was introduced with the fix for BUG91453 where the default was changed so that allowWindowOps was false as shown by :

# resize
COLUMNS=80;
LINES=24;
export COLUMNS LINES;
# resize -s 25 80
resize: unknown character, exiting.



Reproducible: Always

Steps to Reproduce:
1.xterm
2.resize -s 25 80
3.

Actual Results:  
an obscure error shown

Expected Results:  
window resized or a clear explanation of why it didn't work which doesn't require digging into the sources

the security problems that required the ebuild fix were put in place because of a user assisted exploit which abused the title modification, resizing was disabled as a side effect.

the default in Debian/Ubuntu, Fedora/RedHat and upstream is to have this option enabled by default as the fix for the specific attack path used was fixed upstream in version 218

[Comment 1 Niko Efthymiou 2008-08-03 19:20:52 UTC]

I can verify this. Same behavior here.

[Comment 2 Thomas Dickey 2008-09-14 17:20:27 UTC]

resizing (and moving the window around) are disabled when allowWindowOps
is false for the obvious reason (anything that would prevent a user from
accessing the window).  The "resize" program would normally send back
a timeout message; but for the case shown, is seeing an unexpected
escape sequence reply.  Either way, it's handling the error - it's not
going to print out the unexpected escape sequence (though for debugging,
it might be nice to print a sanitized version of it).

[Comment 3 Samuli Suominen (RETIRED) 2009-05-05 19:46:09 UTC]

Am I reading this correctly that this is a "feature" or a "setting", not a bug?

[Comment 4 Thomas Dickey 2009-05-05 20:08:21 UTC]

yes - it's something that the user can override.

Depending on how it's packaged, it might be awkward
(for instance if the packager has set a too-specific
pattern for the resource value).

[Comment 5 Samuli Suominen (RETIRED) 2009-05-06 09:29:30 UTC]

(In reply to comment #4)
> yes - it's something that the user can override.
> 
> Depending on how it's packaged, it might be awkward
> (for instance if the packager has set a too-specific
> pattern for the resource value).
> 

/usr/share/X11/app-defaults/XTerm has *allowWindowOps:        false

And our ebuild tells at the end (elog) following,

elog "bracketed paste mode requires the allowWindowOps resource to be true"
elog "which is false by default for security reasons (see bug #91453)."
elog "To be able to use it add 'allowWindowOps: true' to your resources"

That was previously behind USE flag called "paste64" but that flag is gone,
I believe because we don't change the upstreams (yours I assume :-) setting for it that ./configure passes to the build.. which I assume enables it by default.

So.. I don't see what we should change here.. closing..