On 3/30/23 11:13, Stephen Frost wrote:
>> Okay, but this is walking back from the network example you just
>> described upthread. Do you still consider that in scope, or...?
>
> The concern around the network certainly needs to be in-scope overall.
Sounds good!
> Who are we trusting with what?
On 3/30/23 05:58, Robert Haas wrote:
> On Fri, Mar 24, 2023 at 5:47 PM Jacob Champion
> wrote:
>> Okay, but this is walking back from the network example you just
>> described upthread. Do you still consider that in scope, or...?
>
> Sorry, I don't know which example you mean.
The symmetrical p
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On 3/20/23 09:32, Robert Haas wrote:
> > I think this is the root of our disagreement.
>
> Agreed.
I've read all the way back to the $SUBJECT change to try and get an
understanding of the questions here and it's not been easy, in par
On Fri, Mar 24, 2023 at 5:47 PM Jacob Champion wrote:
> Okay, but this is walking back from the network example you just
> described upthread. Do you still consider that in scope, or...?
Sorry, I don't know which example you mean.
> > If machines B and C aren't under our control such that we can
On 3/20/23 09:32, Robert Haas wrote:
> I think this is the root of our disagreement.
Agreed.
> My understanding of the
> previous discussion is that people think that the major problem here
> is the wraparound-to-superuser attack. That is, in general, we expect
> that when we connect to a databas
On Fri, Mar 10, 2023 at 7:00 PM Jacob Champion wrote:
> On Thu, Mar 9, 2023 at 6:17 AM Robert Haas wrote:
> > That seems like a circular argument. If you call the problem the
> > confused deputy problem then the issue must indeed be that the deputy
> > is confused, and needs to talk to someone el
On Thu, Mar 9, 2023 at 6:17 AM Robert Haas wrote:
> That seems like a circular argument. If you call the problem the
> confused deputy problem then the issue must indeed be that the deputy
> is confused, and needs to talk to someone else to get un-confused. But
> why is the deputy necessarily conf
On Wed, Mar 8, 2023 at 5:44 PM Jacob Champion wrote:
> Sure. I don't see a way for the proxy to figure that out by itself,
> though, going back to my asymmetry argument from before. Only the
> server truly knows, at time of HBA processing, whether the proxy
> itself has authority. If the proxy kne
On Wed, Mar 8, 2023 at 5:44 PM Jacob Champion wrote:
>
> On Wed, Mar 8, 2023 at 11:40 AM Robert Haas wrote:
> > On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion
> > wrote:
> > > I don't think I necessarily like that option better than SASL-style,
> > > but hopefully that clarifies it somewhat?
> >
On Wed, Mar 8, 2023 at 11:40 AM Robert Haas wrote:
> On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion wrote:
> > I don't think I necessarily like that option better than SASL-style,
> > but hopefully that clarifies it somewhat?
>
> Hmm, yeah, I guess that's OK.
Okay, cool.
> I still don't love it,
On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion wrote:
> > No, that's the opposite, and exactly the point I'm trying to make. In
> > that case, the SERVER says what it's willing to accept, and the CLIENT
> > decides whether or not to provide that. In your proposal, the client
> > tells the server wh
On Tue, Mar 7, 2023 at 11:04 AM Robert Haas wrote:
>
> On Thu, Feb 9, 2023 at 4:46 PM Jacob Champion wrote:
> > On 2/6/23 08:22, Robert Haas wrote:
> > > I don't think that's quite the right concept. It seems to me that the
> > > client is responsible for informing the server of what the situatio
On Thu, Feb 9, 2023 at 4:46 PM Jacob Champion wrote:
> On 2/6/23 08:22, Robert Haas wrote:
> > I don't think that's quite the right concept. It seems to me that the
> > client is responsible for informing the server of what the situation
> > is, and the server is responsible for deciding whether t
On 2/6/23 08:22, Robert Haas wrote:
> I don't think that's quite the right concept. It seems to me that the
> client is responsible for informing the server of what the situation
> is, and the server is responsible for deciding whether to allow the
> connection. In your scenario, the client is not
On Wed, Feb 1, 2023 at 3:37 PM Jacob Champion wrote:
> > I'm not an expert on this stuff, but to me that feels like a weak and
> > fuzzy concept. If the client is going to tell the server something,
> > I'd much rather have it say something like "i'm proxying a request
> > from my local user rhaas
On Mon, Jan 30, 2023 at 2:21 PM Robert Haas wrote:
> On Mon, Jan 30, 2023 at 4:12 PM Jacob Champion
> wrote:
> > For our case, assuming that connections have side effects, one
> > solution could be for the client to signal to the server that the
> > connection should use in-band authentication o
On Mon, Jan 30, 2023 at 4:12 PM Jacob Champion wrote:
> For our case, assuming that connections have side effects, one
> solution could be for the client to signal to the server that the
> connection should use in-band authentication only; i.e. fail the
> connection if the credentials provided are
On Fri, Jan 27, 2023 at 1:08 PM Robert Haas wrote:
> > 1) Forwarding the original ambient context along with the request, so
> > the server can check it too.
>
> Right, so a protocol extension. Reasonable idea, but a big lift. Not
> only do you need everyone to be running a new enough version of
>
On Wed, Jan 25, 2023 at 6:22 PM Jacob Champion wrote:
> Sure: Ambient authority [1] means that something is granted access based
> on some aspect of its existence that it can't remove (or even
> necessarily enumerate). Up above, when you said "I cannot choose not to
> be myself," that's a clear ma
On 1/24/23 12:04, Robert Haas wrote:
> I find the concept of "ambient authentication" problematic. I don't
> know exactly what you mean by it. I hope you'll tell me,
Sure: Ambient authority [1] means that something is granted access based
on some aspect of its existence that it can't remove (or ev
20 matches
Mail list logo
