Thread: trust auth in 7.4
Hi,
docs say (19.2.1):
When trust authentication is specified, PostgreSQL assumes that anyone who
can connect to the server is authorized to access the database as whatever
database user he specifies (including the database superuser). This method
should only be used when there is adequate operating system-level
protection on connections to the server.
but nowadays one can specify users in pg_hba.conf, and 19.1 says:
user
Specifies which PostgreSQL users this record matches. The value all
specifies that it matches all users. Otherwise, this is the name of a
specific PostgreSQL user. Multiple user names can be supplied by
separating them with commas. Group names can be specified by preceding
the group name with +. A file containing user names can be specified by
preceding the file name with @. The file must be in the same directory
as pg_hba.conf.
Which of these is right? I hope the last also holds for 'trust' lines?
(and yes, i know you don't want to use this :-))
Regards,
--
Henk van Lingen, Systems & Network Administrator (o- -+
Dept. of Computer Science, Utrecht University. /\ |
phone: +31-30-2535278 v_/_
http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/
On Thu, Jan 22, 2004 at 03:33:05PM +0100, Henk van Lingen wrote: > > but nowadays one can specify users in pg_hba.conf, and 19.1 says: one other thing about this: the pg_hba.conf shipped with 7.4.1 PGDG RPMs for RHEL 3 has: # CAUTION: The default configuration allows any local user to connect # using any PostgreSQL user name, including the superuser, over either # Unix-domain sockets or TCP/IP. If you are on a multiple-user # machine, the default configuration is probably too liberal for you. # Change it to use something other than "trust" authentication. but the only active line is: local all all ident sameuser which seems not quit what was said above, to me. Regards, -- Henk van Lingen, Systems & Network Administrator (o- -+ Dept. of Computer Science, Utrecht University. /\ | phone: +31-30-2535278 v_/_ http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/
Henk van Lingen <henkvl@cs.uu.nl> writes:
> the pg_hba.conf shipped with 7.4.1 PGDG RPMs for RHEL 3 has:
> # CAUTION: The default configuration allows any local user to connect
> # using any PostgreSQL user name, including the superuser, over either
> # Unix-domain sockets or TCP/IP. If you are on a multiple-user
> # machine, the default configuration is probably too liberal for you.
> # Change it to use something other than "trust" authentication.
Which is correct for a stock built-from-source installation.
> but the only active line is:
> local all all ident sameuser
> which seems not quit what was said above, to me.
The RPM distribution changes the default authentication setup. Seems
like that patch ought to adjust the comments too ... Lamar?
regards, tom lane
On Thu, Jan 22, 2004 at 15:33:05 +0100, Henk van Lingen <henkvl@cs.uu.nl> wrote: > Hi, > > docs say (19.2.1): > > When trust authentication is specified, PostgreSQL assumes that anyone who > can connect to the server is authorized to access the database as whatever > database user he specifies (including the database superuser). This method > should only be used when there is adequate operating system-level > protection on connections to the server. > > but nowadays one can specify users in pg_hba.conf, and 19.1 says: > > user > > Specifies which PostgreSQL users this record matches. The value all > specifies that it matches all users. Otherwise, this is the name of a > specific PostgreSQL user. Multiple user names can be supplied by > separating them with commas. Group names can be specified by preceding > the group name with +. A file containing user names can be specified by > preceding the file name with @. The file must be in the same directory > as pg_hba.conf. > > Which of these is right? I hope the last also holds for 'trust' lines? Both. The second part says that in pg_hba.conf you can say which postgres users can connect to which databases. The first part says that trust authentication says that postgres will allow you to be whatever user you want without having to prove it in any way.
On Thu, Jan 22, 2004 at 11:00:25AM -0600, Bruno Wolff III wrote: > > docs say (19.2.1): > > > > When trust authentication is specified, PostgreSQL assumes that anyone who > > can connect to the server is authorized to access the database as whatever > > database user he specifies (including the database superuser). This method > > Which of these is right? I hope the last also holds for 'trust' lines? > > Both. The second part says that in pg_hba.conf you can say which postgres > users can connect to which databases. The first part says that trust > authentication says that postgres will allow you to be whatever user you > want without having to prove it in any way. Well, i think the first part is misleading. Trying it it seems to work as i hoped. If i have a line like host somedb bruno 192.168.5.5 255.255.255.255 trust bruno can connect from 192.168.5.5 but tom can't. I think the first part should say 'as the users specified in the specific pg_hba.conf line without doing further checks'. Never mind. Regards, -- Henk van Lingen, Systems & Network Administrator (o- -+ Dept. of Computer Science, Utrecht University. /\ | phone: +31-30-2535278 v_/_ http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/
On Thu, Jan 22, 2004 at 18:11:36 +0100, Henk van Lingen <henkvl@cs.uu.nl> wrote: > > host somedb bruno 192.168.5.5 255.255.255.255 trust > > bruno can connect from 192.168.5.5 but tom can't. It isn't clear whether you are referring to postgres or OS users above. The OS user tom can connect as the postgres user bruno from 192.168.5.5.
On Thu, Jan 22, 2004 at 11:56:10AM -0600, Bruno Wolff III wrote: > > > > host somedb bruno 192.168.5.5 255.255.255.255 trust > > > > bruno can connect from 192.168.5.5 but tom can't. > > It isn't clear whether you are referring to postgres or OS users above. > > The OS user tom can connect as the postgres user bruno from 192.168.5.5. Of course, I was referring to postgres users. I think the doc can be clearer. If you disagree, never mind :-) Regards, -- Henk van Lingen, Systems & Network Administrator (o- -+ Dept. of Computer Science, Utrecht University. /\ | phone: +31-30-2535278 v_/_ http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/
I know I can write plpgsql functions that return sets. Does postgres support returning multiple sets from a function? Bill McMilleon
bill.postgresql-users@mcmilleon.com wrote: > I know I can write plpgsql functions that return sets. > Does postgres support returning multiple sets from a function? No. Joe
<bill.postgresql-users@mcmilleon.com> writes:
> Does postgres support returning multiple sets from a function?
Not directly. You can fake it in some cases by returning several open
cursors and expecting the caller to fetch from those cursors. However,
if you can't write SQL queries that can be executed to return each of
the needed return sets, you're out of luck --- there's nothing so
flexible as RETURN NEXT.
I don't think this is an unfixable limitation; the needed mechanisms
all exist, it's a matter of figuring out what a reasonable syntactic
representation would look like. Any thoughts?
regards, tom lane
Bruno Wolff III wrote: > On Thu, Jan 22, 2004 at 15:33:05 +0100, > Henk van Lingen <henkvl@cs.uu.nl> wrote: > > Hi, > > > > docs say (19.2.1): > > > > When trust authentication is specified, PostgreSQL assumes that anyone who > > can connect to the server is authorized to access the database as whatever > > database user he specifies (including the database superuser). This method > > should only be used when there is adequate operating system-level > > protection on connections to the server. > > > > but nowadays one can specify users in pg_hba.conf, and 19.1 says: > > > > user > > > > Specifies which PostgreSQL users this record matches. The value all > > specifies that it matches all users. Otherwise, this is the name of a > > specific PostgreSQL user. Multiple user names can be supplied by > > separating them with commas. Group names can be specified by preceding > > the group name with +. A file containing user names can be specified by > > preceding the file name with @. The file must be in the same directory > > as pg_hba.conf. > > > > Which of these is right? I hope the last also holds for 'trust' lines? > > Both. The second part says that in pg_hba.conf you can say which postgres > users can connect to which databases. The first part says that trust > authentication says that postgres will allow you to be whatever user you > want without having to prove it in any way. This patch clarifies that the user column still applies for 'trust'. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/client-auth.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/client-auth.sgml,v retrieving revision 1.62 diff -c -c -r1.62 client-auth.sgml *** doc/src/sgml/client-auth.sgml 13 Dec 2003 23:59:06 -0000 1.62 --- doc/src/sgml/client-auth.sgml 26 Jan 2004 05:33:29 -0000 *************** *** 535,542 **** <para> When <literal>trust</> authentication is specified, <productname>PostgreSQL</productname> assumes that anyone who can ! connect to the server is authorized to access the database as ! whatever database user he specifies (including the database superuser). This method should only be used when there is adequate operating system-level protection on connections to the server. </para> --- 535,543 ---- <para> When <literal>trust</> authentication is specified, <productname>PostgreSQL</productname> assumes that anyone who can ! connect to the server is authorized to access the database with ! whatever database user they specify (including the database superuser). ! Of course, restrictions placed in the <literal>user</> column still apply. This method should only be used when there is adequate operating system-level protection on connections to the server. </para>