> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of RB > Sent: Monday, November 16, 2009 6:46 PM > To: rsyslog-users > Subject: Re: [rsyslog] Feedback request: ACLs, imudp and > accepting messages > > On Mon, Nov 16, 2009 at 09:54, Rainer Gerhards > <[email protected]> wrote: > > I agree, but many people seem to use this functionality, and it was > > introduced some years ago by request. I do not feel > comfortable with the idea > > of removing support for it. The newer protocols do not > support ACLs in any > > case. > > > > Are there some more voices in regard to removing that > functionality? Would > > make the implementation (and probably the throughput) a bit > simpler/faster. > > I agree with david's assessment that "security" by this type of ACL is > minimally effective.
>From a security POV, it may be more effective to remove that option, at least for UDP (people than know it is not secure, but neither is a similar firewall setting). But I fear all those broken configs, then without any protection at all. Maybe a thing for a new v5 default, but even then... > However, the functionality is occasionally > useful for situations where management of the software is easier than > management of the firewall (typically for business/operational > constraints). I'd love to see it reimplemented as a modular part of > the ephemeral "middle layer" along with other filtering and > modification functionality. I fail to see the interface you envision. Could you elaborate a bit? That would be most useful. I guess that a lot of this can now be done by the custom parsers, it may just need to be documented as a valid use case. > I know RanierScript is supposed to fill a > lot of that void, but until it's implemented and proven performant My thinking is moving a bit away from this "once size fits all" approach, primarily for performance reasons. It is quite expensive to start up a full scripting engine (with its VM), so native code loadable modules require more work to be done upfront, but are much faster. Rainer > my > wishes still lie with a filter layer API. > > >> I agree that fewer messages will probably be lost by > accepting them and > >> checking later than by pausing to do the check initially. > > Ditto - although conceptually pure, front-end checking is probably too > expensive for such a performance-critical component as the receiver. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
