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)
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 |