By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,934 Members | 1,685 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,934 IT Pros & Developers. It's quick & easy.

trust auth in 7.4

P: n/a
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/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 22 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 22 '05 #2

P: n/a
Henk van Lingen <he****@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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #3

P: n/a
On Thu, Jan 22, 2004 at 15:33:05 +0100,
Henk van Lingen <he****@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.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 22 '05 #4

P: n/a
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/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 22 '05 #5

P: n/a
On Thu, Jan 22, 2004 at 18:11:36 +0100,
Henk van Lingen <he****@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.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 22 '05 #6

P: n/a
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/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 22 '05 #7

P: n/a


I know I can write plpgsql functions that return sets.
Does postgres support returning multiple sets from a function?

Bill McMilleon
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #8

P: n/a
bi*******************@mcmilleon.com wrote:
I know I can write plpgsql functions that return sets.
Does postgres support returning multiple sets from a function?


No.

Joe
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #9

P: n/a
<bi*******************@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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 22 '05 #10

P: n/a
Bruno Wolff III wrote:
On Thu, Jan 22, 2004 at 15:33:05 +0100,
Henk van Lingen <he****@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
pg***@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>
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 22 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.