Description of problem: Debian/Ubuntu has had support for "aclexec" option in /etc/hosts.allow and/or /etc/hosts.deny in tcp_wrappers via a custom patch since 2006. That option is very handy for being able to integrate custom user provided ACL scripts for controlling access to services. An example how one might use "aclexec" in "/etc/hosts.allow": servicename: ALL: aclexec /usr/local/bin/aclfilter.sh %a if "aclfilter.sh" returns TRUE for the connecting IP then access is allowed, but if it returns FALSE access is denied. Very handy for integrating DNS RBL's and other IP databases via custom scripts. Version-Release number of selected component (if applicable): tcp_wrappers-7.6-76.fc20.x86_64 Actual results: Fedora doesn't provide support for the aclexec option today. Expected results: Fedora provides support for aclexec option, like Debian and Ubuntu do. Additional info: Debian tcp_wrappers changelog: http://archive.debian.net/changelogs/pool/main/t/tcp-wrappers/current/changelog.html which contains an entry from 2006: "New patch aclexec: adds the aclexec command and its documentation". We could grab the aclexec patch from Debian/Ubuntu and apply it to Fedora's tcp_wrappers aswell. Documentation about aclexec: http://manpages.ubuntu.com/manpages/trusty/man5/hosts_options.5.html RUNNING OTHER COMMANDS aclexec shell_command Execute, in a child process, the specified shell command, after performing the %<letter> expansions described in the hosts_access(5) manual page. The command is executed with stdin, stdout and stderr connected to the null device, so that it won't mess up the conversation with the client host. Example: smtp : ALL : aclexec checkdnsbl %a executes, in a background child process, the shell command "checkdnsbl %a" after replacing %a by the address of the remote host. The connection will be allowed or refused depending on whether the command returns a true or false exit status.
Created attachment 985141 [details] Proposed dist git patch I used Debian patch: http://anonscm.debian.org/cgit/users/md/tcp-wrappers.git/commit/?h=patch-queue/master&id=51e7d82c0b6abf9cfaaccaeda185e6eeda05539b After applying patch to our sources and defining -DACLEXEC for build, and resolving some issues I managed to update patch (see attached) and create scratch build [1]. Pasi, can you have a look at this package if it does what is intended? It works for me on rawhide. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8750977
Great, thanks! I should be able to test it next week. I'll report back then.
Hmm, it seems the rpms for the patched version are not available anymore: For example: https://kojipkgs.fedoraproject.org//work/tasks/978/8750978/tcp_wrappers-7.6-79.fc22.src.rpm : You don't have permission to access /work/tasks/978/8750978/tcp_wrappers-7.6-79.fc22.src.rpm on this server.
I built a local custom rpm on f21 based on tcp_wrappers-7.6-79.fc22.src.rpm and the patch from attachment 985141 [details] (linked above). I tested the self-built aclexec-patched binary rpms on Fedora 21, and it seems to work OK for me. Simple test-case setup was like this: /etc/hosts.deny: ALL: ALL /etc/hosts.allow: sshd: ALL : aclexec /usr/local/bin/acltest.sh %a /usr/local/bin/acltest.sh : #!/bin/bash exit 0 Logging in via ssh works OK with the above settings. When I change the "acltest.sh" script to "exit 1" all ssh connections are refused with the following entry in /var/log/secure: Feb 22 22:07:17 f21test01 sshd[2363]: aclexec returned 1 Feb 22 22:07:17 f21test01 sshd[2363]: refused connect from 192.168.122.1 (192.168.122.1) I also verified $1 parameter for the "acltest.sh" script is the actual IP of the connecting client. So it seems to work OK for me. So i'm hoping this patch will make it to F22. Thanks a lot!
Thanks for response and testing. Pushing into rawhide and f22.
Now that this has soaked for 2 years, is there any chance this patch could get applied to RHEL7? We'd love this capability for our servers.
Peter, the RHEL7 bug for this feature is bug #1212380, which describes why this functionality was not added in RHEL7. Adding it now sounds very unlikely, since we plan to deprecate this functionality in close future. See the discussion thread on fedora-devel/fedora-users: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2IBVP66BM6HUZVRTFIVURNZUR2XSUMOD/