Subject: Re: [netatalk-admins] a cold wind bloweth

From: [email-masked]
Date: Wed, 9 Jun 1999 14:13:33 -0500 (CDT)

On 9 Jun 1999, William P. McGonigle wrote:

> --- [email-masked] wrote:
> Does one NEED tcp wrappers to run atalk on Solaris?
> --- end of quote ---
> 
> You start getting into philosophical issues here.  
> 
> Some people would say that you should make it as easy as possible to get up and
> running with netatalk.  This means no security.

It's not philosophical at all netatalk is netatalk and not TCPwrappers.
The TCPwrappers people should worry about TCPwrapper problems.  Expecting
netatalk people to worry about TCPwrapper problems is foolish.  Besides,
when I install netatalk I just want to install netatalk not netatalk and
TCPwrappers.  I can get my own, and possibly more recent version of
TCPwrappers.  Modularity is good not evil.  Besides, perhaps all of my
boxes are behind a firewall and I don't need the overhead of TCPwrappers
at all.

> Netatalk can get a bad wrap from being hard to use or as a potential security
> risk.   I think hard to use is the better choice, myself.

I disagree, users hate to be patronized.  If netatalk gets a bad rep for
being a security hole then it is rightfully so and that's why one should
use firewalling or TCPwrapping with it.  I'd rather have netatalk get a
bad rep than a bad wrap. (pun intended)

Tom

---

From: Michael Han <[email-masked]>
Date: Wed, 09 Jun 1999 12:28:02 -0700

Previously...
>bad rep than a bad wrap. (pun intended)

The point is that if you distribute a precompiled binary of netatalk,
TCP wrapper support is a *compile-time* option. Once you've got a
built binary, you can't go back and add the support for wrappers
(actually, I think you can, but not the easy way). So does the package
builder assume the package installer wants security or doesn't want
it?

Good package management systems allow a system to declare
dependencies. netatalk should be distributed built with wrappers, and
simply require wrapper support and declare this fact through the
package dependency.

At least that's my opinion. Feel free to disagree, but if we're
talking about RPM, there are contrib'd TCP wrappers packages and it
should be easy enough to write netatalk's spec file to require that
package.
-- 
[email-masked]
The Christmas pageant does not stink
 - The collected wisdom of Bart Simpson

---

From: [email-masked] (William P. McGonigle)
Date: 09 Jun 99 12:12:44 EDT

--- end of quote ---

Some would say that you shouldn't let users shoot themselves in the foot, even
if it means preventing them from getting work done.

I'd distribute an RPM with crypt (should be legal now) and wrappers.  That
assumes that someone smart enough to do a source build is smart enough to
consider the security ramifications; not necessarily true but probably a
reasonable approximation.

But I'm not doing the build.

-Bill

---

From: Wenchi Liao <[email-masked]>
Date: Wed, 09 Jun 1999 14:50:59 -0500

>boxes are behind a firewall and I don't need the overhead of TCPwrappers

The problem here is that tcpwrapper is just an example of stuff that
has to be compiled in. I could have used afs and krb as well.

My point whether we can agree on a base install (eg: no des, no afs, no
krb, no pam, and no tcpwrappers). If the base install is no des and no
wrappers, than I (and I'm sure a lot of other people) just won't use
it. Which kinda defeats the purpose of having an rpm of it.

Granted, precompiled stuff isn't for everybody, but it is a bit
annoying when 2/3 of problems/questions deal with a particular bad rpm
build, or when people try to compile netatalk without reading the
README that talks about where to get a copy of libdes.

As alluded to by others, the best approach seems to be a brave soul to
``volunteer'' to create a tarball/rpm with certain options on a certain
platform, with a known destination for the files.

WL

---

From: [email-masked]
Date: Wed, 9 Jun 1999 15:24:14 -0500 (CDT)

> builder assume the package installer wants security or doesn't want

Hmmm, can you compile it for TCPwrappers and not use it?  How hard is it
to add TCPwrappers support programatically.  If one can run netatalk
compiled for TCPwrappers without TCPwrappers installed then that's how it
should be distributed.  If one can't run it in this manner but you can add
it later then there should be another package which either has just the
deltas or a complete package.  Otherwise it should be distributed with and
without TCPwrapper support.  TCPwrappers themselves should not be
distributed in the same package with netatalk.

> simply require wrapper support and declare this fact through the

I'm not too familiar with RPMs, but elswhere there is a clear distinction
between a dependency and a prerequisite.  I'll leave enumeration of
differences as an exercise to the reader.  I think that a weak case could
be made for making TCPwrappers a dependency, but definitely not a
prerequisite.

Tom

---

From: [email-masked]
Date: Thu, 10 Jun 1999 09:32:09 -0400

> From:    [email-masked]
> To:      [email-masked]

> If one can run netatalk
> should be distributed.

Comments from the routine hosts_access(), the main tcp_wrappers routine:

    * If the (daemon, client) pair is matched by an entry in the file
    * /etc/hosts.allow, access is granted. Otherwise, if the (daemon,
    * client) pair is matched by an entry in the file /etc/hosts.deny,
    * access is denied. Otherwise, access is granted. A non-existent
    * access-control file is treated as an empty file.

So, if the admin doesn't have the tcp_wrappers config files on the
machine, tcp_wrappers is effectively turned off.  Voila.

:wes

---

From: [email-masked]
Date: Thu, 10 Jun 1999 21:11:18 -0500 (CDT)

> machine, tcp_wrappers is effectively turned off.  Voila.

Yes.  I have no objections to compiling this in.  I object to including
tcpd or any other pure TCP wrapper tool into the package.

Tom

---

From: [email-masked]
Date: Fri, 11 Jun 1999 00:08:54 -0400

> tcpd or any other pure TCP wrapper tool into the package.

The way a stand-alone daemon like afpd uses tcp_wrappers is with
host_access(), host_ctl(), etc, library calls.  So, no need for tcpd
itself.

:wes

---

From: [email-masked]
Date: Thu, 10 Jun 1999 23:23:27 -0500 (CDT)

> host_access(), host_ctl(), etc, library calls.  So, no need for tcpd

Exactly, so let's compile it in and call it a day, but not include any
other TCP wrapper binaries.

Tom