TCP Wrappers section (handbook/security): services is not daemons

[Denis Peplin]

Hello!

Yes, i see now that using word "daemon" for services is
tradition here :)

It will not be a big problem, if we will add short
description for this "term" (explain tradition) in
beginning of the section.

Tom Rhodes wrote:
> On Thu, 14 Oct 2004 12:24:59 +0200
> "Simon L. Nielsen" <simon at freebsd.org> wrote:
> 
> 
>>On 2004.10.14 13:59:25 +0400, Denis Peplin wrote:
>>
>>["s/daemons/services/g" in TCP Wrappers section]
>>
>>>Please, look at patch attached.
>>
>>Personally I don't care much either way, but hosts_access(5) at least
>>refers to the server programs as "daemons".  Snip from host_access(5):
>>
>>                 daemon_list : client_list [ : shell_command ]
>>
>>       daemon_list is a list of one or more daemon process names (argv[0] val-
>>       ues) or wildcards (see below).
> 
> 
> I won't object to the patch; as if being the author gives me
> any more right.  But I would like to point out that to my knowledge
> every book I've seen which discussed tcpwrappers used 'daemon'.
> 
> Think of it this way, a daemon 'qpopper' offers POP3 mail access,
> to allow this service you need to add qpopper to hosts.allow.
> If you just list pop3, you'll see everything break.
> 
> I consider a daemon a utility/program/whatever the item that
> delivers the service we need, as in the example above.  Since
> I know that I'm not alone in that train of thought, I'll let
> you choose.  If you say "just add the service" then you'll
> break the ACL in TCP Wrappers for every instance that the service
> is not the name of the daemon:
> 
> ...
> 
> nevermind, I really can't think of an example other than services
> marked 'internal' in inetd.conf; those have no external daemon
> associated with them.
>