| From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Andreas(dot)Zeugswetter(at)telecom(dot)at, jwieck(at)debis(dot)com, pgsql-hackers(at)hub(dot)org |
| Subject: | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) |
| Date: | 1998-02-19 19:30:54 |
| Message-ID: | Pine.NEB.3.95.980219143005.17102Z-100000@hub.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > > > Just curious, but why don't the copy command fall under the same
> > > > grant/revoke restrictions in the first place? It sounds to me like we are
> > > > backing off of the problem instead of addressing it...
> > >
> > > grant/revoke works for copy.
> >
> > Ah, okay, so when we have it setup so that a view overrides the
> > 'grant' of a select, then we're fine?
>
> Yep, but can we do that in nine days, and be sure it is tested?
I don't think so...but I'rather have the obviuos "select * from
pg_user" closed off, and the more obscure "copy pg_user to stdout" still
there then have both wide open...its a half measure, but its better then
no measure...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Wieck | 1998-02-19 19:45:46 | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) |
| Previous Message | Bruce Momjian | 1998-02-19 19:26:03 | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) |