[linux] 5.x: userland writes to /usr/lib64/firefox/libxul.so

[m.a. perry]

Good evening Udo,
Thanks for the tip-off. My Debian-10 box runs Firefox-ESR 68.6.1.
I couldn''t find a file called libxul.so in /usr/lib64/ ... even a firefox
directory doesn't exist. But I did strike oil in /usr/lib/firefox-esr/.
The size of the libxul.so file was 105.7 MB. Two more points arise:
--  on the first attempt to open the file my favourite text editor
     played back to me some .eps code I had written this morning
     but then the editor hung up.
--  repeated attempts to open the file, copies of the file, all failed
     and the editor process had to be killed in a terminal.
Sorry that it's just a preliminary input. But you have woken me up
and tomorrow I'll start searching ...
Again thanks.
-----------------
Goeden avond Udo,
Bedankkt voor de tip. Mijn Debian-10 box draait Firefox-ESR 68.6.1. Het 
is mij
niet gelukt om een bestand libuxl.so in het map /usr/lib64/ terug te kunnen
vinden .... ook bestaat er geen map firefox. Wel is het mij gelukt om 
een map
/usr/lib/firefox-esr te vinden waarin een libuxl.so bestand zich bevond.
Dit bestand was 105,7 MB groot! Nog twee punten:
--  na het eerste poging om het bestand met mijn lievelings teksteditor te
     openen, heeft deze wat .eps code weergegeven, die ik vanochtend 
geschreven
     heb; daarna stopte de teksteditor dood.
--  verder pogingen om het bestand, of kopieen daarvan, te openen lukten 
niet
      en werd ik noodgedwongen de editor dmv het terminal te "killen".
Mijn excuses dat ik slechts een voorlopige input kan verstrekken. Maar 
je hebt
mij wakker geschud en morgen ga ik alweer aan de slag.
Nog een keer bedankt
H.gr.
Mike Perry
---------------------------------------------------------------------
On 09/04/2020 15:21, Udo van den Heuvel wrote:
> Hello,
>
> In a bug at https://bugzilla.redhat.com/show_bug.cgi?id=1789477 we found
> that firefox (running as a user) can somehow, sometimes write to
> /usr/lib64/firefox/libxul.so when it (partly) crashes.
> This may point to a situation that should not occur: the library in
> question is owned by root and not writable by the user via conventional
> methods.
> Can anyone confirm this?
> How can we approach to solving this issue?
> Is this a possible kernel issue?
> Or perhaps a linker issue?
>
> Please explain...
>
> Kind regards,
> Udo

------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <https://lists.nllgg.nl/pipermail/linux/attachments/20200409/8e81f05d/attachment.htm>