allowing programs to open ports (was: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break)

Stephen John Smoogen smooge at gmail.com
Sun Dec 21 18:18:10 UTC 2014


On 21 December 2014 at 09:28, Björn Persson <Bjorn at rombobjörn.se> wrote:

> Mattia Verga wrote:
> >The alternative could be a "open approach" from Firewalld, where an
> >application, when it's executed, can inform firewalld that needs to
> >open a port, firewalld asks the user if it should grant access to the
> >application and then opens the port... but this needs to be
> >implemented in the source of every application, it can eventually be
> >sponsored to become a standard in the linux world.
>
> There is already a way for an application to inform the operating system
> that it needs to open a port. It's called the Berkeley socket API, and
> every program that communicates across a network already uses it. Why
> don't you guys patch GlibC's implementations of bind and connect to
> notify FirewallD and get it automatically enabled in every program,
> instead of requiring every communicating program to call a second API in
> addition to the Berkeley socket API?
>
>
I am expecting because the patch would break other things and would be
something that upstream would not want accept to glibc. With Fedora not
wanting to put in patches not accepted by upstream it would be less
accepted that firewalld is.


> Alternatively, cut out the packet filter and have GlibC ask the user
> whether the call to bind or connect shall be allowed to succeed (or
> automatically allow or deny the call if so configured). This has the
> advantage that the program is informed that it's not allowed to
> communicate.
>
> --
> Björn Persson
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141221/5c15d13d/attachment.html>


More information about the devel mailing list