Re: [HACKERS] Query cancel and OOB data

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: mgittens(at)gits(dot)nl, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Query cancel and OOB data
Date: 1998-05-24 17:35:16
Message-ID: 199805241735.NAA09746@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> "Maurice Gittens" <mgittens(at)gits(dot)nl> writes:
> > Assuming that every user has a password which is known by both the client
> > and the server, it seem to me like using a one-way function based on the
> > clientuser password as the secret key (refered to above) is appropiate.
> > This avoids the need for introducing "yet another shared secret into the
> > system".
>
> Well, I think that the cancel security mechanism ought to be per backend
> process, not per user. That is, simply being the same "Postgres user"
> should not give you the ability to issue a cancel; you ought to be
> required to have some direct association with a particular client/backend
> session. Access to the client/backend connection channel is one way;
> knowledge of a per-connection secret is another.
>
> Also, isn't it true that not all the supported authentication mechanisms
> use a password? Taking this approach would mean we have to design a new
> cancel security mechanism for each authentication protocol.

Yes, most connections don't have passwords. Better to keep cancel
separate.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1998-05-24 18:28:50 Re: [HACKERS] Bug in postgresql-6.3.2 (AIX specific)
Previous Message Bruce Momjian 1998-05-24 17:20:27 Re: [HACKERS] Query cancel and OOB data