Thread: More network functions...

More network functions...

From

Sean Chittenden

Date:

18 May 2004, 19:28:08

Blah, well, guess I do need the server's address after all.  The
attached patch includes:

*) inet_(client|server)_(addr|port)() and necessary documentation for
the four functions.
*) area(PATH) and documentation.
*) Checks for TEMP privs when creating objects in the temp schema
(checks for any object created in a temp namespace).
*) With the above change, current_user is now being used to check if
CREATE TEMP TABLE should succeed.
*) Now cleaning up failed getaddrinfo_all() calls.
*) The check for hintp being null has been removed, all calls to
getaddrinfo_all() are passing non-null hintp's.
*) Changed some freeaddrinfo_all() calls to make sure that the addrinfo
struct is non-null.  getaddrinfo_all() can fail and return a null
addrinfo struct and can fail with a non-null addrinfo struct.
*) Updated an error message to include the library path that failed
(handy for debugging old configs that contain $lib instead of $libdir)
*) warn if getaddrinfo_all() fails on postmaster startup.
*) Functions have been updated to be inline with PostgreSQL's style too.

Comments or feedback?

test=# SELECT inet_client_addr();
  inet_client_addr
------------------
  127.0.0.1
(1 row)

test=# SELECT inet_client_port();
  inet_client_port
------------------
             52711
(1 row)

test=# SELECT inet_server_port();
  inet_server_port
------------------
              5432
(1 row)

test=# SELECT inet_server_addr();
  inet_server_addr
------------------
  127.0.0.1
(1 row)


--
Sean Chittenden

Attachment

patch.txt

Re: More network functions...

From

Tom Lane

Date:

19 May 2004, 00:53:47

Sean Chittenden <sean@chittenden.org> writes:
> *) inet_(client|server)_(addr|port)() and necessary documentation for
> the four functions.
> *) area(PATH) and documentation.
> *) Checks for TEMP privs when creating objects in the temp schema
> (checks for any object created in a temp namespace).
> *) With the above change, current_user is now being used to check if
> CREATE TEMP TABLE should succeed.
> [ and it gets weirder from there ]

Er, what?

Could we possibly have this separated into multiple patches with some
coherent purpose to each?

Also, please justify the temp-related changes.  I was not aware that we
had any breakage there.

            regards, tom lane

Re: More network functions...

From

Sean Chittenden

Date:

19 May 2004, 04:28:28

>> *) inet_(client|server)_(addr|port)() and necessary documentation for
>> the four functions.
>> *) area(PATH) and documentation.
>> *) Checks for TEMP privs when creating objects in the temp schema
>> (checks for any object created in a temp namespace).
>> *) With the above change, current_user is now being used to check if
>> CREATE TEMP TABLE should succeed.
>> [ and it gets weirder from there ]
>
> Er, what?
>
> Could we possibly have this separated into multiple patches with some
> coherent purpose to each?

Sure.

patch-network.txt contains the following bits:

*) inet_(client|server)_(addr|port)() and necessary documentation for
the four functions.


> Also, please justify the temp-related changes.  I was not aware that we
> had any breakage there.

patch-tmp-schema.txt contains the following bits:

*) Changes pg_namespace_aclmask() so that the superuser is always able
to create objects in the temp namespace.
*) Changes pg_namespace_aclmask() so that if this is a temp namespace,
objects are only allowed to be created in the temp namespace if the
user has TEMP privs on the database.  This encompasses all object
creation, not just TEMP tables.
*) InitTempTableNamespace() checks to see if the current user, not the
session user, has access to create a temp namespace.

The first two changes are necessary to support the third change.  Now
it's possible to revoke all temp table privs from non-super users and
limiting all creation of temp tables/schemas via a function that's
executed with elevated privs (security definer).  Before this change,
it was not possible to have a setuid function to create a temp
table/schema if the session user had no TEMP privs.

Originally you'd brought up some concerns about security problems, but
this patch I believe addresses all of your prior concerns.


patch-area-path.txt contains:

*) Can now determine the area of a closed path.


patch-dfmgr.txt contains:

*) Small tweak to add the library path that's being expanded.

I was using $lib/foo.so and couldn't easily figure out what the error
message, "invalid macro name in dynamic library path" meant without
looking through the source code.  With the path in there, at least I
know where to start looking in my config file.


-sc



--
Sean Chittenden

Attachment

Re: More network functions...

From

Bruce Momjian

Date:

26 May 2004, 18:35:48

Patch applied.  Thanks.

---------------------------------------------------------------------------


Sean Chittenden wrote:
> >> *) inet_(client|server)_(addr|port)() and necessary documentation for
> >> the four functions.
> >> *) area(PATH) and documentation.
> >> *) Checks for TEMP privs when creating objects in the temp schema
> >> (checks for any object created in a temp namespace).
> >> *) With the above change, current_user is now being used to check if
> >> CREATE TEMP TABLE should succeed.
> >> [ and it gets weirder from there ]
> >
> > Er, what?
> >
> > Could we possibly have this separated into multiple patches with some
> > coherent purpose to each?
>
> Sure.
>
> patch-network.txt contains the following bits:
>
> *) inet_(client|server)_(addr|port)() and necessary documentation for
> the four functions.
>
>
> > Also, please justify the temp-related changes.  I was not aware that we
> > had any breakage there.
>
> patch-tmp-schema.txt contains the following bits:
>
> *) Changes pg_namespace_aclmask() so that the superuser is always able
> to create objects in the temp namespace.
> *) Changes pg_namespace_aclmask() so that if this is a temp namespace,
> objects are only allowed to be created in the temp namespace if the
> user has TEMP privs on the database.  This encompasses all object
> creation, not just TEMP tables.
> *) InitTempTableNamespace() checks to see if the current user, not the
> session user, has access to create a temp namespace.
>
> The first two changes are necessary to support the third change.  Now
> it's possible to revoke all temp table privs from non-super users and
> limiting all creation of temp tables/schemas via a function that's
> executed with elevated privs (security definer).  Before this change,
> it was not possible to have a setuid function to create a temp
> table/schema if the session user had no TEMP privs.
>
> Originally you'd brought up some concerns about security problems, but
> this patch I believe addresses all of your prior concerns.
>
>
> patch-area-path.txt contains:
>
> *) Can now determine the area of a closed path.
>
>
> patch-dfmgr.txt contains:
>
> *) Small tweak to add the library path that's being expanded.
>
> I was using $lib/foo.so and couldn't easily figure out what the error
> message, "invalid macro name in dynamic library path" meant without
> looking through the source code.  With the path in there, at least I
> know where to start looking in my config file.
>
>
> -sc
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

>
>
> --
> Sean Chittenden

>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

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