Re: [HACKERS] libpq port number handling
Sam Mason s...@samason.me.uk writes: Hum, why is PG doing an (unchecked) atoi on the user specified port rather than leaving it up to getaddrinfo to resolve the port? It would seem to require changing UNIXSOCK_PATH to accept a string as the port number, which is probably a bit much of a change. The included doesn't feel very nice, but is probably more acceptable. Applied, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] libpq port number handling
On 25 sep 2009, at 02.59, Tom Lane t...@sss.pgh.pa.us wrote: Sam Mason s...@samason.me.uk writes: +if (portnum 1 || portnum 65535) BTW, it strikes me that we could tighten this even more by rejecting target ports below 1024. This is guaranteed safe on all Unix systems I know of, because privileged ports can only be listened to by root- owned processes and we know the postmaster won't be one. I am not sure whether it would be possible to start the postmaster on a low-numbered port on Windows though. Anyone know? Even if it's possible, do we want to allow it? Windows doesn't care. A non privileged process can open any port, both above and below 1024. Other than that, I agree with previous comments - restricting this in libpq won't actually help anything, but in a few limited cases it will be very annoying. /Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] libpq port number handling
On Thu, 2009-09-24 at 20:36 -0400, Tom Lane wrote: BTW, are port numbers still limited to 16 bits in IPv6? Port numbers are in TCP, not in IP. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] libpq port number handling
On Fri, Sep 25, 2009 at 09:29:24AM +0300, Peter Eisentraut wrote: On Thu, 2009-09-24 at 20:36 -0400, Tom Lane wrote: BTW, are port numbers still limited to 16 bits in IPv6? Port numbers are in TCP, not in IP. I'd checked that it should work with IPv6, but I hadn't realized that it was because ports were at a different level of abstraction. This mailing list is good for otherwise obscure details like that! -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] libpq port number handling
On Thu, Sep 24, 2009 at 07:57:55PM +0100, Sam Mason wrote:
postg...@sussy:/root createuser -D -p ricky
I don't think you want to be passing -p here; it's saying to use
ricky as the port number, which fails (sounds like a bug if it doesn't
complain about this) giving a port number of zero
Hum, why is PG doing an (unchecked) atoi on the user specified port
rather than leaving it up to getaddrinfo to resolve the port? It would
seem to require changing UNIXSOCK_PATH to accept a string as the port
number, which is probably a bit much of a change.
The included doesn't feel very nice, but is probably more acceptable.
--
Sam http://samason.me.uk/
--- src/interfaces/libpq/fe-connect.c~ 2009-06-11 15:49:13.0 +0100
+++ src/interfaces/libpq/fe-connect.c 2009-09-24 20:48:53.0 +0100
@@ -817,7 +817,16 @@
/* Set up port number as a string */
if (conn-pgport != NULL conn-pgport[0] != '\0')
+ {
portnum = atoi(conn-pgport);
+ if (portnum 1 || portnum 65535)
+ {
+ appendPQExpBuffer(conn-errorMessage,
+ libpq_gettext(invalid port number \%s\ specified\n),
+ conn-pgport);
+ goto connect_errReturn;
+ }
+ }
else
portnum = DEF_PGPORT;
snprintf(portstr, sizeof(portstr), %d, portnum);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq port number handling
Sam Mason s...@samason.me.uk writes: Hum, why is PG doing an (unchecked) atoi on the user specified port rather than leaving it up to getaddrinfo to resolve the port? It would seem to require changing UNIXSOCK_PATH to accept a string as the port number, which is probably a bit much of a change. The included doesn't feel very nice, but is probably more acceptable. I had been thinking about applying strstr to insist that the string contain only digits (and maybe spaces), but the range check you suggest is probably more useful. Anyone have objections? (BTW, are port numbers still limited to 16 bits in IPv6? If not then this won't do.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq port number handling
On Thu, Sep 24, 2009 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, are port numbers still limited to 16 bits in IPv6? Yes. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq port number handling
Sam Mason s...@samason.me.uk writes: + if (portnum 1 || portnum 65535) BTW, it strikes me that we could tighten this even more by rejecting target ports below 1024. This is guaranteed safe on all Unix systems I know of, because privileged ports can only be listened to by root-owned processes and we know the postmaster won't be one. I am not sure whether it would be possible to start the postmaster on a low-numbered port on Windows though. Anyone know? Even if it's possible, do we want to allow it? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq port number handling
Tom Lane wrote: Sam Mason s...@samason.me.uk writes: +if (portnum 1 || portnum 65535) BTW, it strikes me that we could tighten this even more by rejecting target ports below 1024. This is guaranteed safe on all Unix systems I know of, because privileged ports can only be listened to by root-owned processes and we know the postmaster won't be one. This is just an aside. The recent Linux system allows to assign a part of root privileges (called as capabilities) on a certain process. Example) # setcap cap_net_bind_service=ep /usr/local/pgsql/bin/postgres -- it allows anyone to launch postmaster with cap_net_bind_service capability. $ pg_ctl -o -i -p 100 start $ psql postgres -p 100 psql (8.5devel) Type help for help. postgres=# Even if it's possible, do we want to allow it? I cannot find any merits. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq port number handling
On Thu, 24 Sep 2009, Tom Lane wrote: Sam Mason s...@samason.me.uk writes: + if (portnum 1 || portnum 65535) BTW, it strikes me that we could tighten this even more by rejecting target ports below 1024. Restricting the target port seems like a bad idea. What about a firewall (or ssh tunnel) that did port forwarding. What PG binds to and what a client connects to may not be the same thing. Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq port number handling
On Thu, Sep 24, 2009 at 8:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Sam Mason s...@samason.me.uk writes: + if (portnum 1 || portnum 65535) BTW, it strikes me that we could tighten this even more by rejecting target ports below 1024. This is guaranteed safe on all Unix systems I know of, because privileged ports can only be listened to by root-owned processes and we know the postmaster won't be one. I am not sure whether it would be possible to start the postmaster on a low-numbered port on Windows though. Anyone know? Even if it's possible, do we want to allow it? I don't think we get much benefit out of artificially limiting libpq in this way. In 99.99% of cases it won't matter, and in the other 0.01% it will be a needless annoyance. I think we should restrict ourselves to checking what is legal, not what we think is a good idea. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
