Re: fds beyond 0/1/2

[nisse%lysator.liu.se@localhost (Niels Möller)]

der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

Some comments, without reading the proposal too carefully:

*** Global probing request ***

>> Why is a global request needed?
>
> It's not really _needed_.  It is designed to allow the client to probe
> for the presence of support earlier than the channel request does.

Why do you need to probe for that early? If you need that only in obscure
cases, why not just

1. open a session channel,

2. send the channel-request and observe the reply

3. close the session channel again

Although I have difficulty seeing why you'd ever need to do that in
advance of actually trying to set up the real session with the various
extra fd:s.

If you want to go forward, I'd suggest specifying the fd forwarding
features (preferably as minimalistic as possible), and then leave out
"early probing for random features" until some clear need for that is
demonstrated. I think that ought to be an orthogonal issue.

*** Channel association ***

And *if* you decide to do the channel association thing (rather than
multiple data types on a single channel), consider how that mechanism
works together with association of x11 channels with the corresponding
session (lacking in the RFCs, but IIRC you have some alternative x11
messages of your own that do set that up this more properly).

*** Security implications of unexpected fds ***

When the ssh server is intended to give only limited access to a user
(only certain subsystems, or only exec requests with certain commands),
I can imagine that the started process might be confused or even
compromized if it is started with random fd's being open. E.g., some
crucial libc functions may fail if no fd:s below 256 are available. So
in this case, the client's ability to request that arbitrary fds be
opened may need to be restricted.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.