Advanced search
Log In
New Account
Home My Page Project Cloud Code Snippets Project Openings Canola
Summary Forums Tracker Lists Tasks Docs News Files Home Page Wiki

Bugs: Browse | Download .csv

[#145] Canola configuration causes security risk

Please login

2006-11-30 09:30
Submitted By:
Andrew Flegg (jaffa)
Assigned To:
Gustavo Barbieri (barbieri)
Canola configuration causes security risk

Detailed description
The Canola configuration web server is started at device boot (presumably the reason a reboot is required post-install)
and binds to

This opens unnecessary security risk: it should be started only when "Canola configuration" is started from
the menu, and then bind to to prevent external access to the server over the network.


Date: 2006-12-11 19:58
Sender: Gustavo Barbieri

Fixed in svn revision 1761.

It will, by default, listen to localhost. Users can change it
to anywhere using the web-conf ui.
Date: 2006-12-01 00:36
Sender: Gustavo Barbieri

After some thinking and tests, we agreed that it would be better
to scan things as soon as possible, so users won't have a huge
impact while using Canola.

Scanning is a pain for the 770, that's why we disable every item
while it's happening. You can't even listen to shared music,
because experience is cumbersome, you get some skips and like.

HOWEVER, we know sometimes you replace your 2Gb MMC with another
one, full of files that have nothing to do with Canola... and
them you put another one and another one... doing unnecessary

In order to solve both problems, we have shell scripts
(canola-conf-*.sh) and the applet, so you can immediately stop
the process, or trigger it later as you wish.

Well, this is our first beta! We're here to let you users use
and give us feedback, so the final version would behave better.
I really appreciate your ideas and suggestion, they'll be taken
in account for next beta release.
Date: 2006-11-30 21:03
Sender: Leif Ryge

Why do you need to scan for files when Canola isn't open?
Date: 2006-11-30 18:25
Sender: Gustavo Barbieri

Ok, so the next version will ship with HTTPd bound to localhost.

Also, we exchange the password using HTTP Basic Auth, no encryption
there. I will put an advice so users will know the problem.

About background scanning: it's really simple. If you add some
folder to collection, like "/media/mmc1", and GnomeVFS
notify media was:
 - Removed: it will issue a SQL query like: "DELETE FROM
 - Added: it will launch a scanner, that will walk file system
(opendir(), stat()) and if there is some parsers that matches
the name (regexp), then it will call the parser on that file.

When you start canola-conf (boot time or using DBus activation),
it will trigger a consistency check:
 - SELECT * FROM $TABLE; -> for each result, stat() the file
and check mtime. If it's newer, than re-parse (id3, exif, ...)
the file. If it didn't exist, then remove from DB.

So, there is no runtime file-watching. Scanning may only be triggered
if you remove/add MMC, if you change your collection, if you
request it using DBus or if you started canola-conf (consistency

Also, remember that you can stop the scanning using the Applet
Date: 2006-11-30 18:15
Sender: Andrew Flegg

I don't see a benefit in being able to disable the HTTPD, but
keep the rest of canola-conf running *if* the HTTPD is bound
only to localhost.

How well behaved is the background scanning with regards to the
carefully tuned power management? Hopefully it's not continually
scanning, or even waking up every 1 minutes to do a full scan
of the disk to see if anything's changed?
Date: 2006-11-30 18:10
Sender: Gustavo Barbieri

Just to make clear:
 - /etc/defaults/canola-conf should only disable boot-time startup,
we use DBus activation to bring it up when canola or canola-applet
are started.
 - you can change the port and address it binds too using gconf
(keys /apps/canola-conf/httpd-port and

Now, I need some feedback:
 - Is it ok for you to just listen to localhost or would you
like to have an option to disable Canola-conf httpd (while still
being able to scan for media, the other task of canola-conf)?
 - In which situation canola-conf consumes a lot of memory? It's
just listen of DBus connections, Serve some HTTP pages and scans
for media. Of these, just scan for media should bring some impact,
while it is scanning (you can check that with applet or command
line: Otherwise it's just a process
with 2 threads sleeping, waiting for DBus or GnomeVFS callbacks.

Also, you as power users may like canola-conf-*.sh scripts, you
can look the code and check how to control canola-conf using

Thank you very much for the feedback.
Date: 2006-11-30 17:58
Sender: Marcelo Eduardo

"to not tell users it is accessible to everyone
else on the wlan isn't OK."

Well, actually we did. That's why we set a password there, and
I talk about the possibility of people acessing the web interface
if there's no password in the biggest Canola how to video.

It's a bug for sure, and we are going to fix it, but again for
the process running all the time issue : we had in mind (and
they are all over now) the end users, that don't know what a
terminal is, etc. so we needed to keep a scanner (canola-conf
is also de scanner / folder watch) alive and it worked well for
all the beta testers. Now is time to give advanced users a lot
more power =) so expect a lot of configuration possibilities
for you soon.

Date: 2006-11-30 16:56
Sender: Gustavo Barbieri

Yes, this is known to be an issue, but Canola-conf process doesn't
really do anything. Yet, it's impossible to ensure no-one will
find a bug (ie buffer overflow) and explore it. Also, it runs
as "user", not root.

If you just want to bind to localhost or change the port (menu
item will detect automatically), just set the GConf option:
/apps/canola-conf/httpd-port and /apps/canola-conf/httpd-address:

   gconftool-2 --set /apps/canola-conf/httpd-address --type string

this will bind to "localhost" instead of every available

I'll write a web-conf UI to allow users to change that, wait
it in next release.
Date: 2006-11-30 15:58
Sender: Andre Moreira Magalhaes

Yeah, i can confirm that. We will try to address the issues pointed
here in the next version.

Tnx for the bug report
Date: 2006-11-30 11:54
Sender: Leif Ryge

Oh, look:
Nokia770:~# cat /etc/default/canola-conf
# This is a configuration file for /etc/init.d/canola-conf; it
allows you to
# perform common modifications to the behavior of the canola-conf
# startup without editing the init script (and thus getting
# by dpkg on upgrades).
# Whether or not to run the canola-conf daemon; set to 0
to disable.

Unfortunately though, setting it to zero doesn't actually do
anything that I can tell. After a reboot, I still have two canola-conf
processes running, and a webserver accessible on the network.

(This is after reinstalling it again... a reboot did (of course)
make it go away after I had uninstalled previously)

I realize the benefits of using a web-based configuration interface,
but to not tell users that it is going to stay running when the
app isn't and to not tell users it is accessible to everyone
else on the wlan isn't OK.
Date: 2006-11-30 11:23
Sender: Jussi Kukkonen

This was the first thing I noticed too. In addition to the security
problem, canola-conf seems to use significant amounts of memory
-- not nice when the user doesn't even know it's running all
the time.
Date: 2006-11-30 10:11
Sender: Leif Ryge

I have confimed this bug and am shocked by the callousness!

To make matters worse, after uninstalling Canola using the Application
manager, the webserver is still running! (It now serves a page
that says "File / does not exist.", and ps still shows
two copies of /usr/bin/canola-conf running despite the binary
not existing there anymore).

Attached Files:

Name Download
No Files Currently Attached


Field Old Value Date By
ResolutionAccepted As Bug2006-12-11 19:58barbieri
ProductNone2006-12-11 19:58barbieri
close_date2006-12-11 19:582006-12-11 19:58barbieri
status_idOpen2006-12-11 19:58barbieri
ResolutionNone2006-11-30 16:56barbieri
VersionNone2006-11-30 16:56barbieri
assigned_tonone2006-11-30 16:56barbieri

Terms of Use    Privacy Policy    Contribution Guidelines    Feedback

Powered By GForge Collaborative Development Environment