Hello Fedora devels and users,
more than three years ago, the same topic started discussion if we want this package in Fedora or not and how [1]. The discussion resulted mostly in flames and in the removal of the dependency on tcp_wrappers from systemd. But it was quite agreed that it is considered as a security layer for some users, if they use it correctly, or something that is or should be replaced by firewalls.
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
The complete removal of the package is probably not a wise step, even though we can not find tcp_wrappers in recent SuSE anymore [2]. It is still available in Arch [3] without other tools depending on it. To be fair, Debian [4] is still building tools (for example openssh) with a build-time support for it.
My primary concern is OpenSSH, which upstream dropped support for tcp_wrappers three years ago (late 2014) [5] and since then we are maintaining one more downstream patch. But this effort should be coordinated among other components to simplify the transition for users who insist on using it (using tcpd).
Removing the dependency will also allow us to trim the default install for few more Kb.
If there will be no significant drawbacks, I will progress with filling a system wide change for Fedora 28 and I will pull the maintainers of other tolls using libwrap into the round and discussion.
[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.h tml [2] https://www.rpmfind.net/linux/rpm2html/search.php?query=tcpd&submit =Search+...&system=&arch= [3] https://www.archlinux.org/packages/community/x86_64/tcp-wrappers/ [4] https://packages.debian.org/sid/openssh-server [5] http://www.openssh.com/txt/release-6.7
Thank you for comments and constructive ideas. Regards,
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen jjelen@redhat.com wrote:
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
IIRC, in the past discussion there was quite a lot of people arguing that we actually need one. I personally don't think we as a distribution need a drop-in replacement. However, what we possibly need, is a migration path for already deployed systems using tcp_wrappers. Just dropping tcp_wrappers and potentially leaving deployed services completely open would very irresponsible.
Also we should consider an impact this change will have on our downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon that "splash damage" potentially caused by this change will be bigger there than in Fedora itself.
Michal
On 08/16/2017 11:37 AM, Michal Sekletar wrote:
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen jjelen@redhat.com wrote:
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
IIRC, in the past discussion there was quite a lot of people arguing that we actually need one. I personally don't think we as a distribution need a drop-in replacement. However, what we possibly need, is a migration path for already deployed systems using tcp_wrappers. Just dropping tcp_wrappers and potentially leaving deployed services completely open would very irresponsible.
Also we should consider an impact this change will have on our downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon that "splash damage" potentially caused by this change will be bigger there than in Fedora itself.
On the other hand shipping downstream openssh patch adding this support when there is already similar functionality present in upstream via the Match directive in sshd_config is something I would definitely not vote for.
Tomas
On 16 August 2017 at 05:44, Tomas Mraz tmraz@redhat.com wrote:
On 08/16/2017 11:37 AM, Michal Sekletar wrote:
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen jjelen@redhat.com wrote:
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
IIRC, in the past discussion there was quite a lot of people arguing that we actually need one. I personally don't think we as a distribution need a drop-in replacement. However, what we possibly need, is a migration path for already deployed systems using tcp_wrappers. Just dropping tcp_wrappers and potentially leaving deployed services completely open would very irresponsible.
Also we should consider an impact this change will have on our downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon that "splash damage" potentially caused by this change will be bigger there than in Fedora itself.
On the other hand shipping downstream openssh patch adding this support when there is already similar functionality present in upstream via the Match directive in sshd_config is something I would definitely not vote for.
The main purpose of tcp_wrappers is to allow a 'live' control mechanism to an op level person/program who may not be able to change configuration files without going through change control systems or restart services (for similar reasons).
In various places, changing a startup/shutdown program requires going through all kinds of extra hassles. So having a layer where the 'local' admin can quickly 'stop' some resource usage is required. The tcp_wrappers was the mechanism to do this. This meant that openssh/postfix/etc did not need to be restarted to get the new ips to allow or disallow. A program could go through logs and add/remove hosts to a file without altering other files and thus could be apparmor/selinux policy limited for further protections.
If there is a way to have systemd read from a 'central' file to allow/deny ips without requiring a systemctl reload/restart of all the services that would be useful to know and would be the way to call it a 'replacement' of the original functionality. Then any .service file could just say it is looking at that file for appropriate matches and those that don't need it don't.
Tomas _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, 2017-08-16 at 12:10 -0400, Stephen John Smoogen wrote:
On 16 August 2017 at 05:44, Tomas Mraz tmraz@redhat.com wrote:
On 08/16/2017 11:37 AM, Michal Sekletar wrote:
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen jjelen@redhat.com wrote:
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
IIRC, in the past discussion there was quite a lot of people arguing that we actually need one. I personally don't think we as a distribution need a drop-in replacement. However, what we possibly need, is a migration path for already deployed systems using tcp_wrappers. Just dropping tcp_wrappers and potentially leaving deployed services completely open would very irresponsible.
Also we should consider an impact this change will have on our downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon that "splash damage" potentially caused by this change will be bigger there than in Fedora itself.
On the other hand shipping downstream openssh patch adding this support when there is already similar functionality present in upstream via the Match directive in sshd_config is something I would definitely not vote for.
The main purpose of tcp_wrappers is to allow a 'live' control mechanism to an op level person/program who may not be able to change configuration files without going through change control systems or restart services (for similar reasons).
In various places, changing a startup/shutdown program requires going through all kinds of extra hassles. So having a layer where the 'local' admin can quickly 'stop' some resource usage is required. The tcp_wrappers was the mechanism to do this. This meant that openssh/postfix/etc did not need to be restarted to get the new ips to allow or disallow. A program could go through logs and add/remove hosts to a file without altering other files and thus could be apparmor/selinux policy limited for further protections.
If there is a way to have systemd read from a 'central' file to allow/deny ips without requiring a systemctl reload/restart of all the services that would be useful to know and would be the way to call it a 'replacement' of the original functionality. Then any .service file could just say it is looking at that file for appropriate matches and those that don't need it don't.
AFAIK, that was the feature that was removed from systemd in 2014. It can not work for services (they handle the connections on their own), but it can simply work with systemd sockets (and instanced services).
And the same way it worked for sockets, it will work in future using tcpd by replacing
ExecStart=-/usr/sbin/sshd -i $OPTIONS
with
ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS
in /etc/systemd/system/sshd@.service (for SSHD example). Source [1].
It needs some tweaks to SELinux policy (I am having a look into that), but there is a way for these who need it.
Also using sockets will allow you that every service instance is reading a fresh configuration (in SSHD case).
[1] https://lists.freedesktop.org/archives/systemd-devel/2014-April/018 793.html
Regards,
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
Hello Fedora devels and users,
more than three years ago, the same topic started discussion if we want this package in Fedora or not and how [1]. The discussion resulted mostly in flames and in the removal of the dependency on tcp_wrappers from systemd. But it was quite agreed that it is considered as a security layer for some users, if they use it correctly, or something that is or should be replaced by firewalls.
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
The complete removal of the package is probably not a wise step, even though we can not find tcp_wrappers in recent SuSE anymore [2]. It is still available in Arch [3] without other tools depending on it. To be fair, Debian [4] is still building tools (for example openssh) with a build-time support for it.
My primary concern is OpenSSH, which upstream dropped support for tcp_wrappers three years ago (late 2014) [5] and since then we are maintaining one more downstream patch. But this effort should be coordinated among other components to simplify the transition for users who insist on using it (using tcpd).
Removing the dependency will also allow us to trim the default install for few more Kb.
If there will be no significant drawbacks, I will progress with filling a system wide change for Fedora 28 and I will pull the maintainers of other tolls using libwrap into the round and discussion.
Hello, In Fedora 26, there is over 50 packages using tcp_wrappers as a build- time dependency:
$ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64 389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64 jenslody apcupsd-0:3.14.14-5.fc26.x86_64 tibbs apcupsd-cgi-0:3.14.14-5.fc26.x86_64 apcupsd-gui-0:3.14.14-5.fc26.x86_64 apt-cacher-ng-0:0.9.0-3.fc26.x86_64 kenjiro audit-0:2.7.7-1.fc26.x86_64 sgrubb bacula-client-0:7.4.7-1.fc26.x86_64 slaanesh bacula-director-0:7.4.7-1.fc26.x86_64 bacula-libs-0:7.4.7-1.fc26.x86_64 bacula-storage-0:7.4.7-1.fc26.x86_64 bacula2-client-0:2.4.4-24.fc26.x86_64 limb conserver-0:8.2.1-3.fc24.x86_64 jkastner ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 bizdelnick ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 cyrus-imapd-0:3.0.1-7.fc26.x86_64 landgraf dcmtk-0:3.6.1-4.fc24.x86_64 ignatenkobrain dovecot-1:2.2.31-3.fc26.x86_64 mhlavink exim-0:4.89-1.fc26.x86_64 dwmw2 flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray foghorn-0:0.1.6-12.fc26.x86_64 rohara gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert libvirt-snmp-0:0.0.3-7.fc24.x86_64 mprivozn libyaz-0:5.14.11-6.fc26.x86_64 guidograzioli lldpd-0:0.9.7-5.fc26.x86_64 jhogarth net-snmp-1:5.7.3-15.fc26.x86_64 jsafrane net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64 nfs-utils-1:2.1.1-5.rc4.fc26.x86_64 steved ngircd-0:24-2.fc26.x86_64 ixs nrpe-0:3.0.1-4.fc26.x86_64 smooge nut-0:2.7.4-7.fc26.x86_64 mhlavink ocserv-0:0.11.8-1.fc26.x86_64 nmav openhpi-subagent-0:2.3.4-28.fc26.x86_64 sharkcz openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer openssh-server-0:7.5p1-2.fc26.x86_64 jjelen pptpd-0:1.4.0-11.fc26.x86_64 jskarvad prelude-manager-0:3.1.0-2.fc26.x86_64 totol proftpd-0:1.3.6-1.fc26.x86_64 itamarjp ptpd-0:2.3.1-4.fc24.x86_64 pbrobinson pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart quagga-0:1.1.1-2.fc26.x86_64 mruprich quota-rpc-1:4.03-8.fc26.x86_64 ppisar redir-0:2.2.1-16.fc26.x86_64 itamarjp rpcbind-0:0.2.4-7.rc2.fc26.x86_64 steved rwhoisd-0:1.5.9.6-6.fc26.x86_64 ppisar sendmail-0:8.15.2-14.fc26.x86_64 jskarvad slapi-nis-0:0.56.1-2.fc26.x86_64 abbra sslh-0:1.18-2.fc26.x86_64 jhogarth stunnel-0:5.41-1.fc26.x86_64 tmraz syslog-ng-0:3.9.1-1.fc26.x86_64 marcusk tcp_wrappers-devel-0:7.6-85.fc26.x86_64 jjelen tftp-server-0:5.2-20.fc26.x86_64 jsynacek up-imapproxy-0:1.2.8-0.7.20130726svn14389.fc24.x86_64 cmadams uwsgi-router-access-0:2.0.15-1.fc26.x86_64 kad vsftpd-0:3.0.3-5.fc26.x86_64 msehnout xinetd-2:2.3.15-18.fc26.x86_64 jsynacek
I added the main contacts on these packages to the bcc to let them express their opinions on this proposal and usefulness of tcp_wrappers in case of their package and their upstream community.
This is not a call for immediate action, but more a discussion, if there is a way and will to get rid of this dependency.
As already mentioned, I would like to see that go in one go (eg. Fedora 28) so anyone using them currently, can step back to tcpd or swat to firewall at once for all the services, if possible.
Thanks, Jakub
[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196913 .h tml [2] https://www.rpmfind.net/linux/rpm2html/search.php?query=tcpd&subm it =Search+...&system=&arch= [3] https://www.archlinux.org/packages/community/x86_64/tcp-wrappers/ [4] https://packages.debian.org/sid/openssh-server [5] http://www.openssh.com/txt/release-6.7
Thank you for comments and constructive ideas. Regards, -- Jakub Jelen
On Fri, 18 Aug 2017 17:42:21 +0200 Jakub Jelen jjelen@redhat.com wrote:
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
Hello Fedora devels and users,
more than three years ago, the same topic started discussion if we want this package in Fedora or not and how [1]. The discussion resulted mostly in flames and in the removal of the dependency on tcp_wrappers from systemd. But it was quite agreed that it is considered as a security layer for some users, if they use it correctly, or something that is or should be replaced by firewalls.
So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one?
The complete removal of the package is probably not a wise step, even though we can not find tcp_wrappers in recent SuSE anymore [2]. It is still available in Arch [3] without other tools depending on it. To be fair, Debian [4] is still building tools (for example openssh) with a build-time support for it.
My primary concern is OpenSSH, which upstream dropped support for tcp_wrappers three years ago (late 2014) [5] and since then we are maintaining one more downstream patch. But this effort should be coordinated among other components to simplify the transition for users who insist on using it (using tcpd).
Removing the dependency will also allow us to trim the default install for few more Kb.
If there will be no significant drawbacks, I will progress with filling a system wide change for Fedora 28 and I will pull the maintainers of other tolls using libwrap into the round and discussion.
Hello, In Fedora 26, there is over 50 packages using tcp_wrappers as a build- time dependency:
the query shows packages with run-time (not build-time) dependencies, in some cases it's an indirect dependency, so the actual list is shorter
$ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64 389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64 jenslody apcupsd-0:3.14.14-5.fc26.x86_64 tibbs apcupsd-cgi-0:3.14.14-5.fc26.x86_64 apcupsd-gui-0:3.14.14-5.fc26.x86_64 apt-cacher-ng-0:0.9.0-3.fc26.x86_64 kenjiro audit-0:2.7.7-1.fc26.x86_64 sgrubb bacula-client-0:7.4.7-1.fc26.x86_64 slaanesh bacula-director-0:7.4.7-1.fc26.x86_64 bacula-libs-0:7.4.7-1.fc26.x86_64 bacula-storage-0:7.4.7-1.fc26.x86_64 bacula2-client-0:2.4.4-24.fc26.x86_64 limb conserver-0:8.2.1-3.fc24.x86_64 jkastner ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 bizdelnick ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 cyrus-imapd-0:3.0.1-7.fc26.x86_64 landgraf dcmtk-0:3.6.1-4.fc24.x86_64 ignatenkobrain dovecot-1:2.2.31-3.fc26.x86_64 mhlavink exim-0:4.89-1.fc26.x86_64 dwmw2 flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray foghorn-0:0.1.6-12.fc26.x86_64 rohara gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert libvirt-snmp-0:0.0.3-7.fc24.x86_64 mprivozn libyaz-0:5.14.11-6.fc26.x86_64 guidograzioli lldpd-0:0.9.7-5.fc26.x86_64 jhogarth net-snmp-1:5.7.3-15.fc26.x86_64 jsafrane net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64 nfs-utils-1:2.1.1-5.rc4.fc26.x86_64 steved ngircd-0:24-2.fc26.x86_64 ixs nrpe-0:3.0.1-4.fc26.x86_64 smooge nut-0:2.7.4-7.fc26.x86_64 mhlavink ocserv-0:0.11.8-1.fc26.x86_64 nmav openhpi-subagent-0:2.3.4-28.fc26.x86_64 sharkcz openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer openssh-server-0:7.5p1-2.fc26.x86_64 jjelen pptpd-0:1.4.0-11.fc26.x86_64 jskarvad prelude-manager-0:3.1.0-2.fc26.x86_64 totol proftpd-0:1.3.6-1.fc26.x86_64 itamarjp ptpd-0:2.3.1-4.fc24.x86_64 pbrobinson pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart quagga-0:1.1.1-2.fc26.x86_64 mruprich quota-rpc-1:4.03-8.fc26.x86_64 ppisar redir-0:2.2.1-16.fc26.x86_64 itamarjp rpcbind-0:0.2.4-7.rc2.fc26.x86_64 steved rwhoisd-0:1.5.9.6-6.fc26.x86_64 ppisar sendmail-0:8.15.2-14.fc26.x86_64 jskarvad slapi-nis-0:0.56.1-2.fc26.x86_64 abbra sslh-0:1.18-2.fc26.x86_64 jhogarth stunnel-0:5.41-1.fc26.x86_64 tmraz syslog-ng-0:3.9.1-1.fc26.x86_64 marcusk tcp_wrappers-devel-0:7.6-85.fc26.x86_64 jjelen tftp-server-0:5.2-20.fc26.x86_64 jsynacek up-imapproxy-0:1.2.8-0.7.20130726svn14389.fc24.x86_64 cmadams uwsgi-router-access-0:2.0.15-1.fc26.x86_64 kad vsftpd-0:3.0.3-5.fc26.x86_64 msehnout xinetd-2:2.3.15-18.fc26.x86_64 jsynacek
I added the main contacts on these packages to the bcc to let them express their opinions on this proposal and usefulness of tcp_wrappers in case of their package and their upstream community.
This is not a call for immediate action, but more a discussion, if there is a way and will to get rid of this dependency.
As already mentioned, I would like to see that go in one go (eg. Fedora 28) so anyone using them currently, can step back to tcpd or swat to firewall at once for all the services, if possible.
Dan
For the record, denyhosts currently relies upon the tcp_wrappers functionality in openssh to function. While it's possible to make it manipulate the firewall as well, the whole situation is kind of a mess. (Does it talk to firewalld? What if you're not running firewalld?)
Sadly I know how terrible tcp_wrappers is and so I know it needs to go away. It's just unfortunate that there's no replacement for it besides firewalling, and dealing with the firewall is unfortunately so complicated.
So that's three of my packages that use tcp_wrappers in some way (denyhosts, apcupsd and cyrus-imapd) though I suspect two of those just need the build dependencies dropped.
- J<
On Fri, 18 Aug 2017, Jason L Tibbitts III wrote:
Sadly I know how terrible tcp_wrappers is and so I know it needs to go away.
just because crows trying to protect their young will 'mob' a hawk hunting to feed her young does not make the hawk terrible; latest is not always greatest
I found the ranting toward wrappers unconvincing years ago - - I remain unconvinced that it is terrible code
It's just unfortunate that there's no replacement for it besides firewalling, and dealing with the firewall is unfortunately so complicated.
wrappers will invoke the resolver, and do PTR lookups, and so can do: - hostname based, - domain related, and - absent DNS information based blocking
I know of no way to do these tasks with the 'firewalld' code
-- Russ herrold
On Fri, 2017-08-18 at 13:15 -0500, Jason L Tibbitts III wrote:
For the record, denyhosts currently relies upon the tcp_wrappers functionality in openssh to function. While it's possible to make it manipulate the firewall as well, the whole situation is kind of a mess. (Does it talk to firewalld? What if you're not running firewalld?)
Unfortunately this is not as straightforward as it could be. Checking how Archlinux does it now, they probably go without denyhosts. There is a also a tool sshguard [1], which does quite much the same as fail2ban using configurable backend (firewalld, iptables, ...).
The denyhosts got last update also 10 years ago [2] and we already have quite much 2 alternatives that can do the same using firewalls, so it might be also a time to go for denyhosts. Or not, but clearly document that OpenSSH will not be using hosts.deny anymore.
Sadly I know how terrible tcp_wrappers is and so I know it needs to go away. It's just unfortunate that there's no replacement for it besides firewalling, and dealing with the firewall is unfortunately so complicated.
So that's three of my packages that use tcp_wrappers in some way (denyhosts, apcupsd and cyrus-imapd) though I suspect two of those just need the build dependencies dropped.
That would be great if you could review the dependencies if it is used and drop the bogus dependencies.
[1] https://wiki.archlinux.org/index.php/sshguard [2] https://sourceforge.net/projects/denyhosts/files/
Thanks,
"JJ" == Jakub Jelen jjelen@redhat.com writes:
JJ> The denyhosts got last update also 10 years ago [2] and we already JJ> have quite much 2 alternatives that can do the same using firewalls, JJ> so it might be also a time to go for denyhosts. Or not, but clearly JJ> document that OpenSSH will not be using hosts.deny anymore.
The last denyhosts release was not much over two years ago, actually. https://github.com/denyhosts/denyhosts
I am nominally active with denyhosts upstream, though I just don't have the time to do the things I really want to do (like fix my support for the systemd journal or get firewalld support merged).
JJ> That would be great if you could review the dependencies if it is JJ> used and drop the bogus dependencies.
I can verify that the dependencies are real. There's nothing bogus about them; the functionality works. But if course if tcp_wrappers is really to be retired then they will need to be rebuilt without it.
- J<
On ma, 21 elo 2017, Jason L Tibbitts III wrote:
"JJ" == Jakub Jelen jjelen@redhat.com writes:
JJ> The denyhosts got last update also 10 years ago [2] and we already JJ> have quite much 2 alternatives that can do the same using firewalls, JJ> so it might be also a time to go for denyhosts. Or not, but clearly JJ> document that OpenSSH will not be using hosts.deny anymore.
The last denyhosts release was not much over two years ago, actually. https://github.com/denyhosts/denyhosts
I am nominally active with denyhosts upstream, though I just don't have the time to do the things I really want to do (like fix my support for the systemd journal or get firewalld support merged).
JJ> That would be great if you could review the dependencies if it is JJ> used and drop the bogus dependencies.
I can verify that the dependencies are real. There's nothing bogus about them; the functionality works. But if course if tcp_wrappers is really to be retired then they will need to be rebuilt without it.
For example, slapi-nis has tcp_wrappers support built in. It can be compiled out, all we would lose is NIS plugin not rejecting access to NIS maps from clients that were defined in hosts.deny. Whether somebody relies on this functionality or not, I'm not aware -- at least, I haven't seen any bugs related to that within the FreeIPA NIS integration context for last six or so years.
-
Alexander Bokovoy -
Dan Horák -
Jakub Jelen -
Jason L Tibbitts III -
Michal Sekletar -
R P Herrold -
Stephen John Smoogen -
Tomas Mraz