charm directory permissions now more restrictive

[Stuart Bishop]

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.

[Stuart Bishop (stub)]

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)]

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.

[William Reade (fwereade)]

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.

[Stuart Bishop (stub)]

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.