Re: Publickey subsystem draft posted

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

On Thu, Jul 24, 2003 at 03:42:12PM +0200, Jon Bright wrote:
> The big change.  This is mostly Joseph's suggested text.  I added 
> "agent", "env" and "subsystem" to the restrictions and moved 
> "port-forward" and "reverse-forward" to be attributes, to allow for 
> specification of allowed-host lists.  Additionally integrated Nicolas' 
> suggestion regarding mandatory restrictions.  Finally, added overwrite, 
> with behaviour as discussed.

> [...]

> Integrate the attribute stuff into the list response.  Further, remove 
> the "command" request, since it's no longer useful in light of the 
> additional "add" functionality.  Finally, add a method of discovering 
> the server's supported restrictions.  I'm convinced this will assist in 
> building a sane GUI for this stuff.  The split that's present between 
> "attributes" and "restrictions" makes the response to this request a 
> little messy.  I'm not sure whether it would be better to make the 
> "restrictions" be freestanding attributes, being that they're (as far as 
> I can tell) all boolean.

I think "from" should be added also (i.e., what source addresses a
client may use this key from).

Yeah, all restrictions should be standalone attributes.  Those
restrictions which you modeled as values of the "restrict" attributes
could be standalone attributes with boolean values (or null; if the
attribute is present, the restriction is on, if not, not).

The "subsystem" restriction should go and be replaced by the subsystem
attribute which should list the sub-systems that a user is allowed to
start (if the list empty, then none are allowed; if the attribute is
missing or if the value is "*", then all are allowed).

Cheers,

Nico
--