On Thu, May 28, 2009 at 10:00:46PM +0200, Fons Adriaensen wrote:
> On Thu, May 28, 2009 at 08:23:06AM +0200,
torbenh@... wrote:
>
> > nedko and me came to the conclusion, that there are several reasons, why
> > applications should be forbidden to make some connections.
> >
> > - lash session loading.
> > - connection ACLs
> > - application is dumb.
> >
> > in order to not clutter jack code, with several ideas of how to
> > configure ACL or whatever, the solution seems to b a callback
> > clients can register.
>
> > bool
> > veto_connection( char *client_requesting_connection, char *src_port, char *dst_port )
>
> As one who had to pay 800 Euro last year to repair the damage
> done by one famous app that connected where it shouldn't have
> (this money could have gone to its developers but didn't) I'm
> all pro some form of access restrictions on ports.
>
> But IHMO this veto system has all it takes to create more
> miseray than it could solve - it basically allows any app
> to veto any connection, making it impossible to decide or
> configure this on any higher level. One would need a veto
> system agains clients abusing this to ensure things remain
> sane.
>
> If clients want to restrict access to their own ports that
> is OK. Anything else should not be the business of any
> particular client but be decided higher up.
actually this is what i am fearing a bit too. iE dumb client vetoing
disconnect of their autoconnected ports.
*shiver*
i actually dont expect anybody to be this dumb. but we cant rely on it.
the problem is that i have identified at least 2 clients (which may run
simultaneously) who could take advantage of this feature.
however all clients identified yet, dont have own ports. maybe it would
make sense to exclude clients which own ports from this system ?
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org