| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | Abhijit Menon-Sen <ams(at)oryx(dot)com>, db(at)zigo(dot)dhs(dot)org, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: lastval() |
| Date: | 2005-06-06 05:33:50 |
| Message-ID: | 17801.1118036030@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> The only objection I can see is that it arguably doesn't obey sequence
> permissions: you need SELECT on a sequence to see its currval(), whereas
> lastval() would return the same information without an equivalent
> permission check.
Interesting point ... the nextval() could have been done inside a
SECURITY DEFINER function that has more privilege than the user of
lastval() has. I'm not sure that this is a very interesting information
leak, mind you, but it's something to consider.
You could fix that by remembering exactly which sequence produced
the lastval and checking its permissions ... of course that brings
back the issue of what happens if the sequence has been dropped ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dennis Bjorklund | 2005-06-06 06:02:01 | Re: lastval() |
| Previous Message | Neil Conway | 2005-06-06 05:27:13 | Re: lastval() |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dennis Bjorklund | 2005-06-06 06:02:01 | Re: lastval() |
| Previous Message | Neil Conway | 2005-06-06 05:27:13 | Re: lastval() |