On Mon, 2005-12-12 at 10:05 -0800, Wes Hardaker wrote:
Dave> For the moment, I'd just like agreement to delete the
Dave> registration of the 'acceptAllTraps' directive.
Wes> I think that's a good idea
Thanks - with Thomas' message, that looks like the +3 I needed.
> but are you going to remove just the new
> (duplicate; renamed) token or both of them?
Just "acceptAllTraps" - I wasn't planning to touch
"disableAuthorization" at all (other than to document it!)
Wes> I think we should have at
Wes> least something regardless of what the name is.
Agreed - in fact, I seem to remember arguing for this
with you when the trapd access control first came in :-)
Wes> I think one of the end goals with all of this stuff
Wes> was to support some aspect of wild-carding... thus
Wes> community=* from 127.0.0.1 might be ok, for example,
Wes> but not from elsewhere...
OK - I hadn't been going to raise my ideas for the next
stage until after 5.3 was out of the door, but since
you mentioned this, here's the basic outline:
I'm looking at a multi-stage process of gradually weaker
levels of protection:
1) Specific authorization
(authcommunity l,e,n public 10.0.0.0/8
authuser l,e,n myUser -v someView
etc)
2) Wildcarded authorization
(authcommunity l * localhost
authuser e,n * priv)
3) selectively disabled authorization
(acceptAllTraps log)
4) completely disabled authorisation
(disableAuthorization yes)
The current code implements 1) & 4)
I'd like to reserve "acceptAllTraps" for level 3), where:
acceptAllTraps T
would effectively be equivalent to the level 2) settings:
authcommunity T *
authuser T * noauth
But both 2) and 3) would be additions to think about for 5.3.1
(or possibly 5.4)
Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
