102-350 · Question #102
Which of the following programs uses the hosts.allow file to perform its main task of checking for access control restrictions to system services?
The correct answer is A. tcpd. See the full explanation below for the reasoning.
Question
Options
- Atcpd
- Binetd
- Cfingerd
- Dmountd
- Exinetd
How the community answered
(42 responses)- A79% (33)
- B5% (2)
- C12% (5)
- D2% (1)
- E2% (1)
Community Discussion
10The answer is A, tcpd. That is the TCP Wrappers daemon, and its whole job is to sit between the network and your system services, consulting hosts.allow and hosts.deny before it decides whether to hand off a connection. The other options are real programs, which is exactly why this question feels tricky, but none of them are designed around those access control files. inetd and xinetd manage service spawning and have their own config mechanisms, fingerd and mountd are just specific services that could be wrapped by tcpd, not wrappers themselves. Once you lock in that tcpd equals TCP Wrappers equals hosts.allow, this one becomes a giveaway on the real exam.
tcpd is right, and worth knowing that modern systemd-based distros have mostly phased it out in favor of firewalld or nftables rules, so if the exam is version-specific you want to double-check which generation of Linux they are testing on.
A, tcpd is the TCP wrapper daemon that reads hosts.allow directly. I blanked on this one until I remembered inetd just hands off connections, it does not do the access checking itself.
Right, and for exam purposes that split is a fast two-second recall, tcpd owns the policy enforcement and logs the attempt via syslog, so if a question asks where to look for denied connection records, that is your answer without burning any extra time on it.
Lock in A and keep moving, this one should cost you under 30 seconds. tcpd is the TCP Wrappers binary and its entire job is to intercept service requests and check hosts.allow before deciding whether to hand the connection off, so the link between tcpd and that file is direct and by design. A common trap here is picking xinetd, because xinetd also does access control, but it uses its own config files under /etc/xinetd.d rather than hosts.allow. inetd is the super-daemon that spawns services but relies on tcpd to do the actual allow-or-deny checking, so do not confuse the launcher with the cop at the door.
Good breakdown, and worth adding that hosts.deny acts as the fallback deny list when tcpd does not find a match in hosts.allow, so both files work together as a pair.
Honestly I keep coming back to C, fingerd, because when one of the senior guys at my internship was showing me how finger requests get filtered, he pointed straight to hosts.allow and said that daemon is what actually reads those rules before deciding whether to respond. The way fingerd sits at that boundary between incoming requests and service access just makes it click for me as the one doing the access control check.
Yusuf, your instinct about that boundary makes total sense, but fingerd is actually the service being protected, not the one doing the protecting. It is tcpd, option A, that intercepts the incoming request first and checks hosts.allow before fingerd ever sees the connection.
inetd is the super-server that manages incoming service connections and sits between the network and those services, so it is the natural place where access control checks against hosts.allow would happen. The whole point of running services through inetd is centralized control, and that centralized control includes reading the allow and deny files before handing off a connection.
Dervla, inetd actually hands the connection off to tcpd first, and it is tcpd (the TCP Wrappers daemon) that reads hosts.allow and hosts.deny before deciding whether to pass the connection along to the service, so inetd is the trigger but not the one doing the access control lookup.