Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/kubuntu-easy-zeroconf
Created: 2006-06-09 by JonathanRiddell
Packages affected: avahi, kdenetwork
Provide an easy way to turn on Zeroconf in Kubuntu.
Zeroconf is not installed by default for security reasons, we should have it installed but disabled and provide an easy way to turn it on.
Jack wants to avoid to make any ad hoc configuration to access his network services at home.
Alice is going to several conferences and wants to easily discover the available services or expose services. But, she doesn't want zeroconf to keep running forever for security reasons.
Zeroconf in this spec refers to the dnssd protocol implemented with Avahi, also known as Rendezvous or Bonjour.
Currently Avahi is not installed on the system. Users have to locate the relevant package and install it to make Zeroconf works. To make sure it's not running anymore they have to uninstall it.
KDE has already a Zeroconf stack able to use Avahi in kdelibs, a ioslave allowing to browse services available, and a KControl module to configure of the Zeroconf stack. We will create the necessary facilities to enable Avahi on demand so that it can be installed by default but inactive, this way the system would stay secure by default while not hampering the user experience.
Introduce /etc/default/avahi-daemon file holding an ENABLED_ON_BOOT key, the value will be 0 by default. The /etc/init.d/avahi-daemon would start avahi on boot only when ENABLED_ON_BOOT=1.
- Include avahi-daemon in the desktop seed so it is installed by default, but disabled as above
- Patch kdelibs package so that the KDE Zeroconf stack is disabled by default.
The current KControl module for zeroconf support has a checkbox to enable/disable the KDE Zeroconf stack. This KControl module should be patched so when the "enable zeroconf" tickbox is selected it first enables Avahi in /etc/default/avahi-daemon and if that succeeds it enables it in KDE. It should give the user a warning similar to the current one when enabling CUPS browsing:
Enabling Avahi Zeroconf will open port xxx on your system. This exposes you to the risk of exploiting any security vulnerabilities of the Avahi system. Remote attackers could potentially gain access to your system with the privileges of the "avahi" user.
- Patch the ioslave so that when the user access the ioslave, or when an application tries to expose a service while zeroconf is disabled we popup a dialog like the following one:
-------------------- | Enable Zeroconf? | | [ ] Forever | | [Yes] [No] | --------------------
If the user answers "yes", Avahi is started for this session (using kdesu) and the KDE Zeroconf stack is activated on success. If the "forever" checkbox is checked, we also put ENABLED_ON_BOOT=1 in the /etc/default/avahi-daemon file.
Create a script /usr/share/avahi/enable_browsing with equivalent functionality /usr/share/cups/enable_browsing: it would edit /etc/default/avahi-daemon to change ENABLED_ON_BOOT and reload the settings of the Avahi daemon. This script would be challed when the user ticks Enable Zeroconf. It needs an option to enable Avahi only for the current session, i.e. until explicity turned off or the machine reboots.
- You say that avahi isn't installed at the moment but this question doesn't seem to be addressed. Do you mean (a) avahi will remain not installed by default (ie, this spec only applies to users who ask for it to be installed); (b) avahi will be installed but disabled by default; (c) avahi will be installed on demand somehow (specify). -iwj
- This spec should mention the word "Rendezvous" (the Apple trademark) somewhere, surely ? -iwj
- Description of the presentation to the user of the security implications is sorely lacking. Is the assumption that users who choose to install avahi know what the security implications are and don't need to be told ? -iwj
AchimBohnet: In 'Use cases' two different cases are listed. a) enable permanently b) Just use it now. I still claim that ENABLED_ON_BOOT is not the right solution. Instead I suggest
- install by default only with the stop init.d links -- fulfills kubuntu security policy
- If a user want to enable it permanently, install start init.d links -- handles 1st use case
- script /usr/share/avahi/enable_browsing to start avahi once (1) makes sure it not started again -- handles Alice 2nd use case
I would strongly advise to look at Mac OS X as an example of ZeroConf integration. First of all given use cases are off wall. I had rarely seen user with such problems. Major (as MAJOR) problem and main use case:
Alice and Bob sit on same LAN and Alice wants to copy a (huge) file from Bob.
At moment that trivial use case in Linux is major hurdle - both in home and company environments. You have to know IP addresses. None of FTPDs has usable configuration out of box. SSH/SFTP/SCP are too slow for LAN. There is no point to have window to activate ZeroConf, if other services are in unusable state.
Mac OS X solves that beautifully.
In "System Preferences" > "Network" user has check list of all installed services. User can check in the list to activate network service (ZeroConf a.k.a. Bonjour is active always in Mac OS, but only for LANs; can be also listed as separate service). Services must be installed, but deactivated by default. All services have to have usable configuration out of box (not true for FTPDs at the moment).
In short help description for every service, user is provided with copy-pastable URL (sftp://<ip-address>/, ftp://<ip-address>/) he can send to other user so he can easily access the service and other user files. (To access the service, user has to have an valid account in the system. But that is out of scope)
Also, please, notice that ENABLED_ON_BOOT is very very counter-intuitive to users. (Nor admins would be very happy about extra config/option to take care of). If user modifies in GUI something they expect it to be persistent. If such option is introduced, then the GUI has to control the option.