--On Monday, March 17, 2008 02:29:56 PM -0500 Nicolas Williams
<Nicolas.Williams at sun.com> wrote:
> Here's a thought:
>
> - sshd should be able to read any of the sshd_config(4) params from
> SMF.
Yes. Provided that the ability to read them from /etc/ssh/sshd_config does
not go away.
I'm inclined to prefer that parameters set in the config file (especially
one given explicitly on the command line) take precedence over those found
in SMF. In fact, I believe this is necessary in order to satisfy the
principle of least surprise. Similarly, the as-shipped sshd_config should
contain a comment to the effect that parameters may be set in SMF.
> This could be implemented as follows:
>
> sshd should read $FMRI's config_data/entities property or
> /etc/ssh/sshd_config, and read_server_config() that config file,
> then:
>
> for each keyword in keywords[]
> if $FMRI has a config/$keyword then
> get its value, stringify it and format a line of the
> form <keyword> = <value>, then call
> process_server_config_line() to parse it
>
> This wouldn't be very sensitive to property value types. E.g.,
> boolean SMF props can be formatted as "yes" (true) or "no" (false),
> integers can be formatted as strings, etc... It wouldn't deal well
> with multiple property values, I think.
>
> The fact that process_server_config_line() already exists makes an
> implementation of this fairly simple, I think.
This sounds fine; particularly, using the process_server_config_line()
abstraction seems like the right thing to do.
In the case of multiple property values, I would suggest concatenating them
with space or comma separators and using the resulting string.
Unfortunately, the choice of which separator to use depends on the
parameter in question; directives like AcceptEnv and
{Allow,Deny}{Users,Groups} require spaces, while Ciphers and Protocol
require commas. I suppose one could simply normalize the parsers for these
at the same time SMF support is added.
The Subsystem directive requires special treatment, since it is used
multiple times to declare multiple subsystems. This could be done by
treating a multi-valued subsystem property specially, or by using a
completely different approach for representing subsystems in smf.
>
> Potential problems:
>
> - The keywords listed in $SRC/cmd/ssh/sshd/servconf.c:keywords[] are
> folder to lower case, we might want them to have the case documented
> in sshd_config(4).
>
> - sshd_config(4) parameter names are case-_in_sensitive, but SMF
> property names are case-sensitive.
>
> Maybe an extension to SMF for case-insensitive property lookup would
> be nice. Alternatively sshd could iterate all the properties in the
> config pg and then strcasecmp() them to keywords[] entries.
>
> - The possibility of confusion over multiple props that differ only
> in case. If sshd reads all of them and strcasecmp()s them to
> keywords, then it could warn about this.
I think case-insensitivity is essential. Again, it is required by the
principle of least surprise, since the existing sshd_config file is
case-insensitive with respect to parameter names (and values in many case,
but as you note, that is process_server_config_line()'s problem).
IMHO the cleanest answer would be to extend SMF to provide for
case-insensitive lookups. If the requested property appears more than once
with different case, return it as multi-valued. However, lacking such an
interface, it would also be reasonable for sshd to iterate over all of the
config properties.
> - Performance -- there's ~80 keywords, so does this mean ~80
> door_call()s to SMF? or can libscf get them all in one go?.
Oh, I really hope so. A multiple-lookup interface to SMF would IMHO be a
clear example of optimization which is _not_ premature.
> If the former, will those ~80 door_call()s significantly slow down
> sshd startup? I suspect this will not be a big deal, but you never
> know.
It would offend my sense of asthetics :-)
