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

Re: avahi-daemon



On Fri, Mar 03, 2006, Michael Stone wrote:
> On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote:
> >Do you have any other solution permitting the same functionalities, but
> >without the listening port?  
> No. If someone wants that functionality than that's how they need to get 
> it. The question has always been about what level of effort is necessary 
> on the user's part to enable that functionality.

 My point of view is that installing the application gets them the
 functionalities they'd expect to find in the default setup.

> >But you are doing nice in pointing at typical services running on a
> >desktop machine:
> >- apache2 (and will be even more common with gnome-suer-share and DAV
> >  file sharing)
> >- samba
> You think that's part of a typical desktop system? Fascinating. 

 Yes, I think these are often part of a desktop.

> >Does any of these run chrooted like avahi does?  Samba even runs as
> >root.  Which of samba or avahi has the power to change file ownership,
> >permissions, or simply to serve sensible files such as /etc/shadow?
> You continue with the specious arguments. What non-server dependency 
> pulls in samba? What dependency pulls in gnome-user-share? The argument 
> isn't whether someone who intentionally installs a package should get 
> the functionality of the package, it's about what kind of side-effects 
> might unknowningly be enabled by someone installing an apparantly 
> unrelated package.

 If you find my last arguments were "specious", let me reformulate them for your reading pleasure:
 straight:
 - I believe other apps typically installed on desktop systems are way
   more dangerous that the "big hole" people consider opened by avahi
 - avahi doesn't need a lot of rights to run, by design, and beyond this
   implements the classical security enhancements one expects to find in
   clean daemons

 In other words, even if it opens a new port, I believe this is less a
 security concern for desktops than other typical services.

 Concerning your dependencies remarks, I think I've answered to them
 enough already: this is a Recommends, nothing pulls in rhythmbox from
 a standard install up to a gnome-desktop-environment install, I
 proposed dependencies workarounds for most use cases (have a conflict
 from security packages, use your own meta-package...).

 Frankly, you're not considering the arguments I gave on dependencies,
 you even ignored them multiple times already, and since the core of
 this issue is about dependencies, and the fact that rhythmbox pulls in
 avahi by default, I'm not inclined to be interested in continuation of
 this discussion.

 If you feel there's a technical problem with the technical choices of a
 package or meta-package, bring it as a bug report, linking to this
 discussion, and if you don't get maintainer's agreement, please bring
 it to a technical committee.  It's really here to help take technical
 decision where consensus can not be reached.

-- 
Loïc Minier <lool@dooz.org>
Current Earth status:   NOT DESTROYED



Reply to: