get_file_by_name does not check owner

My first intention was to simply remove the get_by_name() API operation from the anonymous handler. This is what I've done in https://code.launchpad.net/~rvb/maas/fix-get-file-by-name/+merge/187754 and the package I created from it worked fine with juju-core because juju-core uses either authenticated calls or get_file_by_key() to access the files it needs.

Sadly, this is not the case with (py)juju which really needs the anonymous get_by_name() API operation. Note that it needs it to get from the MAAS server files related to charms and which contain a random element (the file names are something like 'mysql-charm-sdfkj56lkjsdflkj4td'). The random element is probably there to mitigate the security risk.

This is rather problematic because the same code has to accommodate both juju-core and (py)juju. We could land my branch above if we choose to abandon pyjuju compatibility.

If we can't abandon PyJuju there might still be something we can do to reduce the problem. If there's a pattern for these filenames - e.g. ^\w+-charm-\w+$ - then perhaps we can permit anonymous access for just these files. It's still a hole, though a smaller one. We could additionally have a config option to permit this, which defaults to false.

Unfixed for a year, can't be critical.

Unless someone really depends on it, we should kill this and deprecate pyjuju support. Can someone check with Alexis, Mark Ramm and Ante to see if this is the case?

Just wrote to them; let's see what they say.

@Kiko: I've testing this in the lab and go juju deploys services all right. Can you please do some more testing on this?

(I'm re-assigning this to you as I'll be travelling tonight and probably unavailable)

We decided to wait till after 1.7 is release in order to publish a fix for this bug, for all the versions of MAAS out there at the same time.

This is ready to land, but we'll hold off until the first point release where we can do a security-only change which we backport to trusty and precise.

This is CVE-2014-1426

What's the status on this issue? Did this get fixed? Does this bug need to remain private?

This security bug has been open for over two years now. I plan on making this bug public on 2016-05-01.