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

[Nicolas Williams <Nicolas.Williams%Sun.COM@localhost>]

On Tue, Aug 29, 2006 at 10:20:52AM +0200, Jon Bright wrote:
> Nicolas Williams wrote:
> 
> SSH2 negotiation negotiates a list of the languages to be used (or 
> doesn't - that negotiation is optional).  The tags specify which of 
> those languages is in use.  (In much the same way that the language tag 
> for, say, SSH_MSG_DISCONNECT does.)
> 
> As for why we don't use Unicode language indicators - no idea, but I'd 
> prefer to keep this consistent with all the messages in the other RFCs 
> which also don't.

I misremembered how the rest of SSHv2 handles this -- usually a language
tag field does accompany localized strings in the protocol.

I think that's kind of useless (what do I do with that tag,
client-side?).  But you are following the pattern from the rest of the
SSHv2 protocol family, so I withdraw my comment re: language tag fields.

> > - I'd rather the "mandatory" attribute of attributes be named
> >   "critical"...
> 
> This would change a sentence like "If the server does not implement a 
> mandatory attribute, it MUST fail the add.." to "If the server does not 
> implement a critical attribute, it MUST fail the add..".  The first 
> seems preferable to me.

The word "critical" is very commonly taken to mean what this doc means
by "mandatory" and there is no chance of confusing it with RFC2119
terminology.  I very strongly encourage this change.  I think it makes
the spec much more readable.

> > - Are attributes like "x11" and so on booleans?  Or does their
> >   presence/absence act as a boolean?  And if so, what kind of values do
> >   they take on?
> 
> Their presence/absence act as boolean.  As for their values, "The 
> attribute-value field SHOULD be empty for this attribute.".

Thanks.

> > - Clients need to know what kind of environment "command-override"
> >   values will be evaluated in. 
> 
> Under what circumstances?

So users (and even programs, I suppose) can properly construct
command-override values.  I don't feel strongly about this though.

> > - How should the command-override and subsystem attributes interact?
> 
> command-override overrides SSH_MSG_CHANNEL_REQUESTs with "shell" or 
> "exec".  subsystem places limits on SSH_MSG_CHANNEL_REQUESTs with 
> "subsystem".  They're independent.

OpenSSH does wrap subsystems with forced_commands, thus my question.

> > - How much of the execution environment of command-overrides be
> >   specified here?
> 
> If I've understood the question correctly: the only thing it specifies 
> is the path.  I don't really know when you'd need to specify more?

Are there environment variables that are set, etc...?  Or are such
details out of scope for your document?

> > - An attribute is needed to set environment variables for the
> >   environment where the command/shell/subsystem is executed.
> 
> Why?  Again, I think it's too late for this kind of substantive change.

Because the facility you patterned this after (right?  OpenSSH?) has a
way to associate environment variables with public keys.

Nico
--