On Tue, 2021-09-07 at 12:24 +0200, Magnus Hagander wrote: > On Wed, Jul 14, 2021 at 8:24 PM Jacob Champion <pchamp...@vmware.com> wrote: > > On Mon, 2021-07-12 at 18:28 +0200, Magnus Hagander wrote: > > > Yeah, I have no problem being stricter than necessary, unless that > > > actually causes any interop problems. It's a lot worse to not be > > > strict enough.. > > > > Agreed. Haven't heard back from the HAProxy mailing list yet, so > > staying strict seems reasonable in the meantime. That could always be > > rolled back later. > > Any further feedback from them now, two months later? :)
Not yet :( I've bumped the thread; in the meantime I still think the stricter operation is fine, since in the worst case you just make it less strict in the future. > (Sorry, I was out on vacation for the end of the last CF, so didn't > get around to this one, but it seemed there'd be plenty of time in > this CF) No worries! > > > The question at that point extends to, would we also add extra > > > functions to get the data on the proxy connection itself? Maybe add a > > > inet_proxy_addr()/inet_proxy_port()? Better names? > > > > What's the intended use case? I have trouble viewing those as anything > > but information disclosure vectors, but I'm jaded. :) > > "Covering all the bases"? > > I'm not entirely sure what the point is of the *existing* functions > for that though, so I'm definitely not wedded to including it. I guess I'm in the same boat. I'm probably not the right person to weigh in. > > Looking good in local testing. I'm going to reread the spec with fresh > > eyes and do a full review pass, but this is shaping up nicely IMO. > > Thanks! I still owe you that overall review. Hoping to get to it this week. > > Something that I haven't thought about very hard yet is proxy > > authentication, but I think the simple IP authentication will be enough > > for a first version. For the Unix socket case, it looks like anyone > > currently relying on peer auth will need to switch to a > > unix_socket_group/_permissions model. For now, that sounds like a > > reasonable v1 restriction, though I think not being able to set the > > proxy socket's permissions separately from the "normal" one might lead > > to some complications in more advanced setups. > > Agreed in principle, but I think those are some quite uncommon > usecases, so definitely something we don't need to cover in a first > feature. Hm. I guess I'm overly optimistic that "properly securing your database" is not such an uncommon case, but... :) --Jacob
