On 20 March 2014 11:34, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
Heya!
I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.
Why would we get rid of them?
Well, to make things simpler, primarily. They have not seen any
development since 2003 (that's 11 years I mind you, an eternity in IT).
I doubt there are many people even using them anymore, firewalls are
more comprehensive and a lot more powerful, and while every admin knows
firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
actively make use of them...
Actually they are used quite a bit in various service worlds. Mainly for ssh and email for dealing with scanners. [DenyHosts is a boon in this area.] The reason for using a secondary tool is that depth of security. Over the years I have found that there are multiple of attacks which will nullify one layer of protection at one point or another. Having a second level or third level of protection is a boon when this happens.
At the enterprise level firewalls can come under a different set of change control rules than something like tcpwrappers which is considered application level. While I would like to be able to make a simple change in a firewall, I can end up spending a month until I can. Application controls are usually an hour or so signoff. This means that if tcp-wrappers is going then something will need to be able to replace it to meet that large scale concern. [Automatic firewall controls like firewalld have to be disabled or put into a manual changes only mode in these areas for change control purposes. ]
I can't argue on the code maintainability or layout. Not my area of expertise. I can say that if tcpd/libtcpwrappers were to go away that something equivalent would need to be built to replace it for the ability to fine tune at a layer below the firewall.
The API is awful, too, with lot's of open-coded structures, feature
checks in the headers, fixed length strings, globally exported variables,
non-namespaced symbols, really weird exported compatibility wrappers for
OS calls...
I'd propose we make a clear cut, and just start disabling it in all
services that link to it, instead of letting rot on in Fedora for all
eternity.
It's bad code, little used, crufty. We have much better stuff now, and
that enables us to say goodbye to the old mess...
I figure there will be a bit of opposition to this change, thus I
thought I start the discussion on the fedora ML first. Unless there are
major concerns I will propose a feature about this in the next few
days. If somebody wants to join me on this and put his name on the
feature proposal I'd be delighted!
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Stephen J Smoogen.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
