Problem: We use different MySQL credentials in the daemons vs the web in the Phacility cluster right now: the daemons get more permissions. This causes every instance to raise the "Daemons and Web Have Differing Config" setup issue.
Here are some possible solutions:
- Use the same credentials for both. My personal assessment here is that the isolation is low-value but valuable enough to retain, so I disfavor this approach.
- In detail, currently, the web can SELECT, INSERT/UPDATE, and DELETE, but can not ALTER. The purpose of different credentials is to increase the barrier an attacker (say, an attacker who discovers an SQL injection hole) faces in doing damage. To this end, we limit the permissions they have. However, SELECT is the most damaging (read private data, read sessions and secrets); then INSERT/UPDATE (change sessions/secrets); then DELETE (destroy data); then ALTER (break the instance, but who cares). So we're isolating the least dangerous permission. Still, we are isolating some capabilities, and I believe there's an attack where you escalate your user's permission by ALTERing the mysql.user table (this is a major escalation, and would let the attacker attack other instances). Neither user has access to this database, though, so it should be irrelevant.
- Ignore this setup issue. This doesn't seem very clean.
- We lose the warning, which is useful/valuable in at least some cases.
- If we set config.ignore-issues in site-level config, it gets overwritten by DB-level config. So we either need to lock it (breaking the ignore button), or deal with it potentially being overwritten by the DB settings (e.g., if we ever want to ignore a second issue, we'd need to migrate every instance).
- Generally feels a little goofy to ship with setup issues.
- Add phd.variant-config or similar, containing a list of keys which are expected to vary. I think this is the cleanest fix.
- Before hashing config, remove all the keys specified by this list.
- Sucks because it adds more config, but fixes the issue pretty cleanly without fallout.
Or maybe there's another approach I haven't thought of yet.