On Tue, Jul 20, 2010 at 12:58 PM, Dave Shield <[email protected]>wrote:
> On 20 July 2010 11:35, Bart Van Assche <[email protected]> wrote:
> > Allowing on-the-fly changes of nsExtendArgs would have severe security
> implications.
>
> Surely that's the role of VACM ?
>
It is possible with VACM to close the security hole that would be created by
making nsExtendArgs modifiable. But users won't like it that upgrading to a
newer Net-SNMP version would create a security hole unless they modify their
snmpd.conf. And users that do not read the release notes carefully would
unknowingly create a security hole by upgrading.
> My proposal for making on-the-fly argument specification
> > possible is as follows:
> > * Add a column in the nsExtendConfigTable with the purpose to allow
> > on-the-fly argument specification, e.g. a column with type OCTET STRING
> and
> > that triggers command execution when set.
>
> > * Make it possible to let the extend directive in snmpd.conf accept that
> > string, e.g. via a percent (%) code. Do this in such a way that extend
> > directives using the current extend format ignore any on-the-fly
> arguments.
>
> I would prefer to address the underlying problem - reviewing how processing
> of configure files work in general. If we can find a mechanism to support
> SET requests on config-file directives safely, this would benefit *all*
> configuration (current and future) - not just extend.
>
Every major project I know of keeps configuration files that are rewritten
by software and configuration files that have been created manually
separate. As an example, for Firefox has the the two configuration files
prefs.js and user.js. There must be a reason for this.
Bart.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
