charm directory permissions now more restrictive

Bug #1205286 reported by Stuart Bishop on 2013-07-26
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
juju-core
Undecided
Unassigned
postgresql (Juju Charms Collection)
Critical
Unassigned
postgresql-psql (Juju Charms Collection)
Critical
Unassigned

Bug Description

Previously, the charm directory was created world readable and a number [1] of charms made use of this by generating stuff in there that needs to be accessible to non-root users.

Now, at least with the local provider, the charm directory is only accessible by the root user.

[1] Well, at least the postgresql-psql charm did.

Related branches

Stuart Bishop (stub) wrote :

Can anyone triage this? I'm dangling as I don't know if the more restrictive permissions are a bug or a feature.

Stuart Bishop (stub) on 2013-08-06
Changed in postgresql (Juju Charms Collection):
status: New → Triaged
importance: Undecided → High
importance: High → Critical
Changed in postgresql-psql (Juju Charms Collection):
status: New → Triaged
importance: Undecided → Critical
Stuart Bishop (stub) wrote :

This change has also broken the PostgreSQL charm - authentication credentials are being stored in the charm directory, and subprocesses running as the postgres user no longer have access to them.

I see three ways of progressing:
  1) Refactor the charms to store their state outside of the charm directory, in /var/lib somewhere I guess.
  2) Revert the change in juju-core
  3) Have the charms override the permissions on the charm directory, taking control themselves.

I really need this triaged in juju-core before I start digging a deeper hole.

Tom Haddon (mthaddon) on 2013-08-13
tags: added: canonical-webops
William Reade (fwereade) wrote :

Sorry we missed this.

It's not quite clear why it doesn't work, because we didn't do anything specific to prevent this; but it's not sensible practice. See doc/charms-in-action.txt in the source tree:

Charm deployment
----------------

  * A charm is deployed into a directory that is entirely owned and controlled
    by juju.
  * At certain times, control of the directory is ceded to the charm (by
    running a hook) or to the user (by entering an error state).
  * At these times, and only at these times, should the charm directory be
    used by anything other than juju itself.

The most important consequence of this is that it is a mistake to conflate the
state of the charm with the state of the software deployed by the charm: it's
fine to store *charm* state in the charm directory, but the charm must deploy
its actual software elsewhere on the system.

To put it another way: deleting the charm directory should not impact the
software deployed by the charm in any way; and there is currently no mechanism
by which deployed software can safely feed information back into the charm
and/or expect that it will be acted upon in a timely way.

Changed in juju-core:
status: New → Won't Fix
Stuart Bishop (stub) wrote :

Thanks. It is clear that the postgresql-psql charm needs fixing.

Slightly more nebulous is the postgresql charm, where hooks run commands as the 'postgres' user and these sub-processes no longer have access to the credentials stored in the charm directory. But it too can be fixed.

Stuart Bishop (stub) on 2013-09-06
Changed in postgresql (Juju Charms Collection):
status: Triaged → Fix Released
Changed in postgresql-psql (Juju Charms Collection):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers