Possible bug in 3.2.7
Jeremy Allison
jra at samba.org
Thu Jan 15 18:04:02 GMT 2009
On Thu, Jan 15, 2009 at 02:16:34PM +0100, Remy Zandwijk wrote:
> Developers,
>
> I believe there is a bug in Samba 3.2.7. Please refer to:
>
> http://marc.info/?l=samba&m=123188218612431&w=2
> "Calling Samba print server with an aliased DNS-name fails"
>
>
>
> I invested some time to investigate this problem.
>
> Somewhere in the process a call to the function 'is_myname_or_ipaddr'
> from lib/util_sock.c is made. Since I am calling the server by it's DNS
> CNAME, /* Handle possible CNAME records - convert to an IP addr. */
> applies.
>
> A call to 'print_sockaddr' is made, which calls print_sockaddr_len, which
> calls sys_getnameinfo and finaly a call to getnameinfo is made.
>
> The getnameinfo system call fails with error 11, which is a system error.
> The reason why this call fails is that the buffer which is being used to
> store the IP-address of the CNAME is too small.
>
> Tracing back to the place were the buffer size is determined, we see that
> this is done in lib/util_sock.c, line 2066 and further:
>
> print_sockaddr(name,
> sizeof(name),
> &ss);
>
> Since I am compiling 64-bit and 'name' is a char*, the buffer size is
> always 8. I believe this is wrong, since an IP-address string will not
> (most of the time) fit in 8 bytes.
>
> To test this, I replace 'sizeof' by 'strlen'. This resolves my problem: I
> can connect to the server by it's CNAME and I can connect to shared
> printers.
>
> However, I think 'strlen' is inappropriate too. A CNAME 'a.b.nl' is only
> 6 bytes in length, so an IP-address will still not fit.
I know what to do here to fix this.
> Browsing through the code, I found more places were 'sizeof' is being
> used. I did not investigate this, but I imagine this could be wrong too.
I'll check.
> Please confirm this indeed is a bug. And please CC me in replies, since I
> am not member of the samba-technical list.
Completely correct. I'm going to log this as a "blocker" bug in the samba
bugzilla and fix it asap.
Jeremy.
More information about the samba-technical
mailing list