charm audit summary

[Gustavo Niemeyer]

On Tue, Oct 16, 2012 at 10:48 AM, William Reade
<william.reade at canonical.com> wrote:
>> In less trivial cases, relations may also be used to create the
>> sequencing between the units, when that's really necessary.
>
> I'm not sure it helps us here -- we can certainly use relation settings
> to nudge the unit on the other side into doing something, and that's
> absolutely how *charms* should be communicating amongst themselves --
> but I am concerned about one charm touching files related to its service
> at the same time as another charm does. Maybe this is just bad hygiene
> on the charm's part, but I'm not sure -- if the subordinate acts only by
> telling the principal to do things, ISTM that that functionality may as
> well be entirely within the principal.

I feel the opposite: imagine you have an haproxy charm and
haproxy-conf subordinates. It feels quite elegant to send
configuration snippets for specific services to the principal, while
it would be very messy to have everyone playing around with the
configuration files directly at their will, no matter whether hooks
are running serially or not.

> So I'm not really concerned about the order in which things run: it's
> just about preventing charms from getting into stupid error states
> because they weren't able to tweak a local config file because another
> hook was doing so simultaneously. Is this scenario crazy?

It's not crazy, but it's strongly discouraged. Nothing on earth will
help us getting different people to mechanically sort out conflicts
changing the same files in a smooth and correct way across the board.
We need charms with proper interfaces in those cases.

> Same unit agent, not same uniter, although I suspect that was just a
> thinko. I'm not 100% sure it's a good idea either... but I am really

I was talking about that as well. One error on one uniter will restart
the agent, compromising the security of one uniter compromises them
all, etc.

> I agree that stability would need to be considered carefully, but I
> don't think security's a concern here: when everything's root within the
> container boundary, I don't think that process boundaries buy us much.

What the charm *runs* may not be running as root.


gustavo @ http://niemeyer.net