Re: Other comments on draft-ietf-secsh-publickey-subsystem

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Aug 30, 2006 at 11:31:33AM -0600, Joseph Galbraith wrote:
> It doesn't seem inappropriate to use "@openssh.org" to express
> an openssh compatibility option.
> 
> In the normal course of events, I wouldn't be opposed to adding
> a standard attribute to the draft, but I'm worried that something
> like that would require us to redo last-call?  And given the
> deadline we are operating under, I suspect this is not a winning
> option.

If I decide that I'm happy with vendor-specific command-override
alternatives then I won't ask you to change the draft and I'll withdraw
my comment.

However, what I requested was simple enough: add text saying that
servers MAY apply command-overrides to subsystems.

I think this MAY should be non-controversial -- there is already way too
much that is left unstated about the environment in which command-
overrides are executed.

For example, OpenSSH sets a number of SSH_* environment variables in the
environment of forced commands to convery information about the
connection and/or channel in the context of which the command is being
executed.  And you would not want to specify such things here.  But by
constraining command-overrides so they do not apply to subsystems you
create a problem.  The MAY and command-override%openssh.com@localhost solutions
both address the problem, but I think the former is easier to understand
for users of this protocol than the latter.  Users already have to know
quite a bit about the environment on the server, such as paths to the
command-override programs, and may even want to write their own, in
which case they have to know even more about the environment.  So asking
users to know whether command-override applies to subsystems seems
reasonable, but asking them to know that command-override%openssh.com@localhost
(or do you expect the client to learn this?) means the same seems like
too much.

Nico
--