)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"1a24905fbb51ae7d3e1471011b65c53231cc0a14","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"805eca60_0587d2a7","updated":"2026-08-31 12:14:06.000000000","message":"Would you mind open a launchpad bug and link the patch to it?","commit_id":"f841c223e41776764e79c0ff436dec68fbe2468c"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"c5320c79b99da4ac4cd3768eb62803110778acf9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"11573d96_222b58c4","updated":"2026-09-09 14:14:05.000000000","message":"Thanks Omer, both points are correct and I don\u0027t have a counter-argument\nfor either.\n\nThe policy one is the more serious of the two. create_pool/update_pool\nare admin-gated, but zone attributes go through update_zone, which any\nproject member owning the zone can call. So this patch lets a tenant\nmake Designate emit NOTIFY packets to an arbitrary host and port of\ntheir choosing. That is not just an inconsistent policy check, it is an\noutbound packet primitive handed to an unprivileged caller. Zone\nattributes are the wrong carrier for this.\n\nThe validation gap follows from the same mistake: PoolAlsoNotify has\nIPOrHost and a port range because it is a real schema field, and I\nbypassed all of it by encoding host:port into a free-form attribute\nstring.\n\nThis is the same shape of concern Jens raised on 991726, where a\nproject-scoped action reaches into what is currently operator-controlled\nterritory. I would rather solve both in one place than patch each\nseparately, so I am folding this into a spec on openstack/designate-specs\ncovering per-zone configuration of authoritative servers outside the\npool. Everything Designate has for that today is pool-scoped and\nadmin-only, and I think a proper answer needs a real field, real\nvalidation, and an explicit decision about who is allowed to set it.\n\nLeaving this open and marked WIP until the spec lands. Happy to abandon\nit instead if you prefer a clean queue.","commit_id":"97cd275b7184cbc63d626acab48f5a061ac29ef3"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"df27a26687794791bdac3f473181e7b642d36f32","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"57f788b2_0ec517d5","updated":"2026-09-02 15:01:04.000000000","message":"Thanks for the patch — the use case (per-zone NOTIFY fan-out without needing a dedicated pool per target) makes sense IMO. I have a few concerns on the authorization/validation model:\n\nPolicy: create_pool/update_pool require role:admin (bare admin check, not project-scoped). Zone attribute updates go through update_zone, which is ADMIN_OR_PROJECT_MEMBER — so any non-admin tenant who owns a zone can set also_notify:* on it.\n\nValidation: PoolAlsoNotify.host/.port are real schema fields (fields.IPOrHost(), fields.IntegerFields(minimum\u003d1, maximum\u003d65535)), with a DB uniqueness constraint. The new zone-attribute path has none of that — it\u0027s a free-form string parsed with \u0027:\u0027 in value and utils.split_host_port, no IP/host or port-range validation.","commit_id":"97cd275b7184cbc63d626acab48f5a061ac29ef3"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"94c7edd829d990e758a4fa383ecb55de297f9ed3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"346ee652_f903e026","updated":"2026-08-31 15:21:20.000000000","message":"recheck grenade failures are not related to the patch","commit_id":"97cd275b7184cbc63d626acab48f5a061ac29ef3"}]}