https://bugzilla.mindrot.org/show_bug.cgi?id=1997
chrysn@fsfe.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chrysn@fsfe.org
--- Comment #3 from chrysn@fsfe.org ---
Given the approach of distinguishing sockets based on their QoS has not
led to a solution (with different hosts being a workaround but IMO not
a well maintainable one), I've run through the sequence and options
with the current versions:
* QoS is still decided after expansion (expansion happens in main; QoS
is set down from there in ssh_session2 / ssh_session2_open /
ssh_session2_setup)
* QoS, unless explicitly configured, is set to interactive based on the
presence of tty_flag || a successful X forwarding.
* tty_flag is set in main based on -t/-T, the presence of a command and
isatty a few lines before the control path expansion.
It should thus be relatively straight-forward to add a token for "is an
interactive session" that would lack the QoS solution's
fine-grainedness (but that comes to play only when explicit QoS
configuration is around anyway, in which case setting the socket would
often be possible in the same config stanca) and its reactivity to the
presence of X forwarding.
Would a patch to add a "%I" for "1 for interactive sessions, 0
otherwise" to the expansion be generally acceptable? Peter, would it
still serve your purposes (given your description sounded like the
added flexibility is more of a bonus than a requirement)? If so, I'd be
happy to write it.
Would it make sense to make the condition `options.forward_x11 ||
tty_flag` rather than plain `tty_flag` to capture the intention of the
forwarding? (I'd rather not, though, as that'd have corner cases of
X11-requested-and-not-granted leading to the wrong priority on the
interactive control master, and would force all connections through the
interactiv path if ForwardX11 is generally enabled; maybe a '%X' could
later be considered for the benefit of those cases, but for here I'd
like to keep it simple.)
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
chrysn@fsfe.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chrysn@fsfe.org
--- Comment #3 from chrysn@fsfe.org ---
Given the approach of distinguishing sockets based on their QoS has not
led to a solution (with different hosts being a workaround but IMO not
a well maintainable one), I've run through the sequence and options
with the current versions:
* QoS is still decided after expansion (expansion happens in main; QoS
is set down from there in ssh_session2 / ssh_session2_open /
ssh_session2_setup)
* QoS, unless explicitly configured, is set to interactive based on the
presence of tty_flag || a successful X forwarding.
* tty_flag is set in main based on -t/-T, the presence of a command and
isatty a few lines before the control path expansion.
It should thus be relatively straight-forward to add a token for "is an
interactive session" that would lack the QoS solution's
fine-grainedness (but that comes to play only when explicit QoS
configuration is around anyway, in which case setting the socket would
often be possible in the same config stanca) and its reactivity to the
presence of X forwarding.
Would a patch to add a "%I" for "1 for interactive sessions, 0
otherwise" to the expansion be generally acceptable? Peter, would it
still serve your purposes (given your description sounded like the
added flexibility is more of a bonus than a requirement)? If so, I'd be
happy to write it.
Would it make sense to make the condition `options.forward_x11 ||
tty_flag` rather than plain `tty_flag` to capture the intention of the
forwarding? (I'd rather not, though, as that'd have corner cases of
X11-requested-and-not-granted leading to the wrong priority on the
interactive control master, and would force all connections through the
interactiv path if ForwardX11 is generally enabled; maybe a '%X' could
later be considered for the benefit of those cases, but for here I'd
like to keep it simple.)
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs