[rsyslog] Feedback request: ACLs, imudp and accepting messages

[Rainer Gerhards]

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com 
> [mailto:rsyslog-bounces at lists.adiscon.com] 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 
> <rgerhards at hq.adiscon.com> 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
>