651786 - Modifying the default user object modifies the DEFAULT_USER constant

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Frédéric Buclin]

my $user = Bugzilla->login;
$user->{xs} = 45;
Bugzilla->logout_request;
print Bugzilla->user->{xs};

returns 45 despite logout_request undef'ines the user object. Note that this only works if you are not logged in, else the last instruction prints undef, as expected.

I don't think this unexpected behavior triggers any security problem, but when fixing it, we should keep in mind that it will probably have side-effects, such as invalidating my fix for bug 650593 (as Bugzilla->logout is called before Bugzilla->user->settings). So that's not something we should take on branches.

Comment 1

[:glob ✱]

i hit this issue via an extension creating a bug during checksetup, prior to Bugzilla::User->super_user being called.  this resulted in "Can't store CODE items at Bugzilla/User.pm line 171" (the dclone line in super_user).

Comment 2

[:glob ✱]

Attachment: 651786_1.patch

this patch replaces dclone with a simple shallow copy, and makes Bugzilla::User->new() use it as well as Bugzilla::User->super_user().

this doesn't break the patch for bug 650593.

Comment 3

[:glob ✱]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/User.pm
Committed revision 8829.

Comment 4

[Olav Vitters]

Could this be applied to Bugzilla 4.4? GNOME hits this sometimes in the Bugzilla 4.4 test installation, see https://bugzilla.gnome.org/show_bug.cgi?id=743171.

Comment 5

[Andre Klapper]

Could this be backported to Bugzilla 4.4 so GNOME does not have to maintain a downstream patch for this?

Comment 6

[:glob ✱]

sorry about the delay; evidently my 'pending approvals' query was only looking for open bugs.

this is fine to backport to 4.4.
To ssh://[e-mail]/bugzilla/bugzilla.git
   981729e..3fbd84b  4.4 -> 4.4