The default bug view has changed. See this FAQ.

Errors when accessing Bugzilla over IPv6

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
Bugzilla-General
RESOLVED FIXED
13 years ago
4 years ago

People

(Reporter: Calum, Assigned: Wurblzap)

Tracking

({regression})

2.18
Bugzilla 2.18
regression
Bug Flags:
approval +
blocking2.20 +
approval2.18 +
blocking2.18.1 +

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040714 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040714 Firefox/0.8

When I access a dual-stack server running Apache 2, with Bugzilla 2.18.0_rc2
using the IPv6 address of the server, I get an error when I try and log in. It
all works OK with IPv4.

Reproducible: Always
Steps to Reproduce:
1. https://my.ipv6.address/bugzilla/
2. Log in
3. See error.

Actual Results:  
index.cgi: DBD::mysql::db selectrow_array failed: called with 4 bind variables
when 3 are needed [for statement ``SELECT profiles.userid, profiles.disabledtext
FROM logincookies, profiles WHERE logincookies.cookie=? AND  
logincookies.userid=profiles.userid AND   logincookies.userid=? AND  
(logincookies.ipaddr=?)'']) at Bugzilla/Auth/Cookie.pm line 67
index.cgi: \tBugzilla::Auth::Cookie::authenticate('Bugzilla::Auth::Cookie',2,7)
called at Bugzilla/Auth/CGI.pm line 104
index.cgi: \tBugzilla::Auth::CGI::login('Bugzilla::Auth::CGI',0) called at
Bugzilla.pm line 74
index.cgi: \tBugzilla::login('Bugzilla',0) called at
/var/www/localhost/htdocs/bugzilla/index.cgi line 41


Expected Results:  
Logged me in as it does with IPv4.
Assignee: justdave → erik

Comment 1

12 years ago
 my ($userid, $disabledtext) = $dbh->selectrow_array($query, undef,
                                                        $login_cookie,
                                                        $login,
                                                    ->  $ipaddr,
                                                    ->  $netaddr);

If I remove $netaddr , it works with IPv6 but no more IPv4, but here is the
output of the IPv4 error:

DBD::mysql::db selectrow_array failed: called with 3 bind variables when 4 are
needed [for statement ``SELECT profiles.userid, profiles.disabledtext FROM
logincookies, profiles WHERE logincookies.cookie=? AND  
logincookies.userid=profiles.userid AND   logincookies.userid=? AND  
(logincookies.ipaddr=? OR logincookies.ipaddr=?)'']) at Bugzilla/Auth/Cookie.pm
line 67
	Bugzilla::Auth::Cookie::authenticate('Bugzilla::Auth::Cookie',22,4) called at
Bugzilla/Auth/CGI.pm line 104
	Bugzilla::Auth::CGI::login('Bugzilla::Auth::CGI',1) called at Bugzilla.pm line 74
	Bugzilla::login('Bugzilla') called at
/usr/local/bugzilla/UPDATE/bugzilla-2.18/buglist.cgi line 81

Here is what is interesting: 
 (logincookies.ipaddr=? OR logincookies.ipaddr=?)

Seems that bugzilla has some trouble to understand IPv6, lets take a look at this:

 my $query = "SELECT profiles.userid, profiles.disabledtext " .
                "FROM logincookies, profiles " .
                "WHERE logincookies.cookie=? AND " .
                "  logincookies.userid=profiles.userid AND " .
                "  logincookies.userid=? AND " .
                "  (logincookies.ipaddr=?";
    if (defined $netaddr) {
        trick_taint($netaddr);
        $query .= " OR logincookies.ipaddr=?";
    }

Maybe that query should always include the optional query?

    if (defined $netaddr) {
        trick_taint($netaddr);
    }
        $query .= " OR logincookies.ipaddr=?";

Thats better! All right, now bugzilla works both with IPv4 and IPv6 ! But why?
Well, 

my $netaddr = Bugzilla::Auth::get_netaddr($ipaddr);

Seem to be confused.

(from Auth.pm)

sub get_netaddr {
    my $ipaddr = shift;

    # Check for a valid IPv4 addr which we know how to parse
    if (!$ipaddr || $ipaddr !~ /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/) {
        return undef;
    }

    my $addr = unpack("N", pack("CCCC", split(/\./, $ipaddr)));

    my $maskbits = Param('loginnetmask');

    $addr >>= (32-$maskbits);
    $addr <<= (32-$maskbits);
    return join(".", unpack("CCCC", pack("N", $addr)));
}

Maybe a patch could be written to enable get_netaddr to deal with IPv6 address?
(Assignee)

Comment 2

12 years ago
Confirming. Happens on trunk and 2.18 branch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Version: unspecified → 2.18
(Assignee)

Comment 3

12 years ago
Created attachment 177474 [details] [diff] [review]
HEAD patch
(Assignee)

Updated

12 years ago
Assignee: erik → wurblzap
Status: NEW → ASSIGNED
Attachment #177474 - Flags: review?
(Assignee)

Comment 4

12 years ago
Created attachment 177475 [details] [diff] [review]
Branch patch
Attachment #177475 - Flags: review?
(Assignee)

Updated

12 years ago
Flags: blocking2.18.1?
I believe this got broken when we introduced the ability to restrict the number
of bits we honor in an IP address, which is a very IPv4-centric thing to do.
Flags: blocking2.20+
Flags: blocking2.18.1?
Flags: blocking2.18.1+
Keywords: regression

Comment 6

12 years ago
Actually, you can honor a number of bits in an IPv6 address, too, if you want.
It's just that the range extends much further, so a /32 is a huge range. :-)

Comment 7

12 years ago
Comment on attachment 177474 [details] [diff] [review]
HEAD patch

r=joel
Attachment #177474 - Flags: review? → review+

Comment 8

12 years ago
FYI - to test this on an IPv4 machine, force getnetaddr to return an undef.
Flags: approval?
Flags: approval2.18?

Comment 9

12 years ago
Comment on attachment 177475 [details] [diff] [review]
Branch patch

r=joel by inspection
(same fix as HEAD)
Attachment #177475 - Flags: review? → review+

Updated

12 years ago
Whiteboard: patch awaiting approval
(In reply to comment #6)
> Actually, you can honor a number of bits in an IPv6 address, too, if you want.
> It's just that the range extends much further, so a /32 is a huge range. :-)

OK, so before I approve this, is our netaddr code actually working on IPv6?  Or
are IPv6 folks going to be stuck with the entire address being bound to the
cookie?  Is our bit width preference only affecting IPv4 addresses then?
(Assignee)

Comment 11

12 years ago
(In reply to comment #10)
> OK, so before I approve this, is our netaddr code actually working on IPv6?
> Or are IPv6 folks going to be stuck with the entire address being bound to
> the cookie?  Is our bit width preference only affecting IPv4 addresses then?

No, yes, and yes :)
Fixing this is not part of this bug; this bug takes care of the logincookies
query not handling its bound parameters correctly.
OK, so anyone accessing over IPv6 is still stuck with the cookie bound to their
entire IP address, but this bug fixes it so it no longer causes an SQL error
trying to find that out.  Got it.  Just trying to make sure I have the story
straight :)
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval+

Comment 13

12 years ago
Tip:

Checking in Bugzilla/Auth/Login/WWW/CGI/Cookie.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Auth/Login/WWW/CGI/Cookie.pm,v  <--
 Cookie.pm
new revision: 1.3; previous revision: 1.2
done


2.18 branch:

Checking in Bugzilla/Auth/Cookie.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Auth/Attic/Cookie.pm,v  <--  Cookie.pm
new revision: 1.2.2.1; previous revision: 1.2
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Whiteboard: patch awaiting approval
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.