The g_file_copy function in glib 2.0 sets the permissions of a target
file to the permissions of a symbolic link (777), which allows
user-assisted local users to modify files of other users, as
demonstrated by using Nautilus to modify the permissions of the user
Created attachment 205029 [details, diff]
Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=593406
The patch covers the following commits:
gnome: can you apply the patch?
See the following discussion on IRC with a3li :
<mrpouet> a3li: ping
<a3li> mrpouet: ¿sì?
<mrpouet> security fix for glib is only for 2.20.5 not for 2.22.2, this patch is already present in 2.22.2 :)
<mrpouet> see timeline (git.gnome.org/cgit/glib)
<mrpouet> there is a tag for 2.22.2 date : 2009-10-07, your patch contains fixes commited before this release bugfixes (2009-10-01)
<a3li> mrpouet: okay. how do you want to proceed?
<mrpouet> so your patch is good just for 2.20.5, so I'll commit this patch for 2.20.5 (with a revbump)
<mrpouet> then we must ask a stablereq in few days
<a3li> mrpouet: and that .5-r1 is your candidate for stabilization then, I guess
<mrpouet> exactly :)
This security fix is only for glib-2.20.5 because glib-2.22.2 already includes it, I commited it for 2.20.5 with a revbump in the main tree :)
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Stbale on alpha.
I found bug 292439 but there is around no chance someone fail on it.
So, ppc stable.
09 Nov 2009; Jeroen Roovers <firstname.lastname@example.org> glib-2.20.5-r1.ebuild:
Stable for HPPA (bug #286102).
Added to pending glsa.
We are running to a three years delay. Is this still worth a glsa ?
This issue has been fixed since Nov 17, 2009. No GLSA will be issued. However, users will be encouraged to update in a future GLSA.