>
> "Maurice Gittens" <mgittens@gits.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@candle.pha.pa.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)