Re: BUG #16695: pg_hba_file_rules NULL address and netmask
От | Tom Lane |
---|---|
Тема | Re: BUG #16695: pg_hba_file_rules NULL address and netmask |
Дата | |
Msg-id | 832503.1604361320@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16695: pg_hba_file_rules NULL address and netmask (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16695: pg_hba_file_rules NULL address and netmask
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > pg_hba_file_rules reports NULL address and netmask values incorrectly on > FreeBSD 11 for tested postgres versions 10-13 (at least). e.g. So for the archives' sake: what I suppose Peter means is that the addr and netmask come out as NULL on every line, even where they should not. At least, that's what I've reproduced here on FreeBSD 11.0. I traced through this, and the proximate cause seems to be that getnameinfo(3) is failing because it is expecting the passed "salen" to be exactly the length it is expecting for the given sa_family. Which it is not, because alone among our callers of pg_getnameinfo_all(), fill_hba_line() thinks it can get away with passing sizeof(struct sockaddr_storage) rather than the actual addrlen previously returned by getaddrinfo(). The POSIX specification for getnameinfo() saith The sa argument points to a socket address structure to be translated. The salen argument contains the length of the address pointed to by sa. so it seems to me that fill_hba_line() is clearly in the wrong. There are evidently a lot of implementations that either don't check salen or only insist it be >= required length, but POSIX doesn't say they need to be that lax. (It'd be interesting to know if anyone sees similar failures on any other BSDen.) The core of the problem is somebody being lazy about what they needed to put into HbaLine. Unfortunately that's an exported structure so there's some small risk of an ABI break, but I guess we can add the length fields at the end in released branches to minimize the hazard. Thanks for the report! regards, tom lane
В списке pgsql-bugs по дате отправления: