[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: avahi-daemon



On Fri, 03 Mar 2006, Loïc Minier wrote:
>  proposed multiple options in other posts, all of them ignored.  People
>  *not* trying for a middle-ground solution are those claiming an open
>  port by default is unacceptable, no matter what.

You will notice I didn't propose you disable open ports by default.  What
part of "ask it using debconf, priority medium or higher, default can be
enabled" tells you do not have open ports for mdns open by default?

> > >  don't want to see running on his server.  Would this discussion happen
> > >  on a multimedia list, the situation would be kind of the opposite, and
> > >  people would be shouting loud if that wasn't pulled in by default.
> > Then they can (read: should) use DeMudi, and DeMudi has all the excuses in
> > the world to ship with all mdns services enabled by default.  The Debian
> > project *officially* recognizes the need for specialized distributions, you
> > know.
> 
>  Or perhaps people wanting total security should create their own distro.

They did, just like the multimedia people.

>  Will you push me in reverting any argument you provide in favor of
>  security the other way around, or is my point sufficiently clear?

See first paragraph reply.

>  Please, bring solutions in this discussion, not arguments, we've got
>  enough already.

See first paragraph reply.

>  Yep, I proposed multiple solutions already, one of which being a
>  debconf-handled setting to start avahi on boot or not (which obviously
>  would need to be set to start by default, as for other daemons).

Well, that has more to do with avahi-server than your mdns app. And if you
look for the thread, you will notice I replied to whomever asked that that
avahi-server should start automatically like just every other daemon in
Debian does, that it made sense to bind avahi-server to IPADDR_ANY, and to
use policy-rc.d if you don't want stuff like that hapenning.

But this still does not mean mdns apps should not have the mdns master
switch.  Unless they *need* avahi-server installed and active to even open
a mdns socket, in which case they don't need to implement anything (the
master switch is avahi-server).

> > The master switch addresses both your needs, and the security ones.  All you
> > need to do is not to hide it if you're shipping it with the default being
> > the less secure choice.
> 
>  I didn't intend to hide it, but it probably won't be high-priority, as
>  we both know how this clutters Debian installs.

Leave it at Medium, it is enough.  Avahi mdns isn't high risk (this does not
apply to zeroconf, but I understand that avahi mdns clients and avahi-server
are a different kettle of fish).

>  I don't know between priority medium and low.  I should probably look
>  at existing debconf-handled settings to get a picture.

Setting it at low defeats the purpose of the question.  The idea is that it
is a *master* switch, no matter how many avahi client apps you install, you
get asked only for the first one.  Since there are (no matter how slight)
security implications, most installs should see it (thus priority medium).

>  And here comes localhost again: it's the fourth time someone mentions
>  listening to localhost in this discussion, which is quite worthless for
>  a publishing / discovery daemon.

It is mentioned as an example that others do *something* to avoid listening
on outside interfaces.  At least to me it is very obvious that in avahi's
case it doesn't make sense to listen on lo only.

You *could*, for a more difficult implementation than the master switch, ask
instead in which interface should avahi servers and clients listen (and
allow for the "none" reply).  I don't think that's worth the trouble,
however, so I didn't suggest it at first.

>  Anyway, I'm not the avahi maintainer, I'm quite sure he would be ok to
>  apply a patch providing the relevant debconf-handled settings, would he
>  get a bug report requesting this.

That's probably the way to go, as it is much better implemented as a shared
debconf template, and avahi's master packages seem the better place to
document it, at the very least.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



Reply to: