1 |
I discovered that I had significant filesystem corruption. |
2 |
|
3 |
|
4 |
|
5 |
On 11/12/20 10:47 AM, n952162 wrote: |
6 |
> |
7 |
> So, /usr/lib/firefox/firefox runs, and is writable only by root. But |
8 |
> it can't be that the full firefox functionality gets executed in |
9 |
> 239364 bytes! |
10 |
> |
11 |
> |
12 |
> $ type firefox |
13 |
> firefox is /usr/bin/firefox |
14 |
> |
15 |
> $ which -a firefox |
16 |
> /usr/bin/firefox |
17 |
> |
18 |
> $ ll /usr/bin/firefox |
19 |
> lrwxrwxrwx 1 root root 24 Nov 16 2019 /usr/bin/firefox -> |
20 |
> /usr/lib/firefox/firefox |
21 |
> |
22 |
> $ ll /usr/lib/firefox/firefox |
23 |
> -rwxr-xr-x 1 root root 239364 Nov 16 2019 /usr/lib/firefox/firefox |
24 |
> |
25 |
> $ file /usr/lib/firefox/firefox |
26 |
> /usr/lib/firefox/firefox: ELF 32-bit LSB pie executable, Intel |
27 |
> 80386, version 1 (SYSV), dynamically linked, interpreter |
28 |
> /lib/ld-linux.so.2, for GNU/Linux 3.2.0, stripped |
29 |
> |
30 |
> I tried this but don't see anything that looks promising: |
31 |
> |
32 |
> $ ldd /usr/lib/firefox/firefox |
33 |
> linux-gate.so.1 (0xb7fb9000) |
34 |
> libpthread.so.0 => /lib/libpthread.so.0 (0xb7f3f000) |
35 |
> libdl.so.2 => /lib/libdl.so.2 (0xb7f3a000) |
36 |
> libstdc++.so.6 => |
37 |
> /usr/lib/gcc/i686-pc-linux-gnu/9.3.0/libstdc++.so.6 (0xb7cbc000) |
38 |
> libgcc_s.so.1 => |
39 |
> /usr/lib/gcc/i686-pc-linux-gnu/9.3.0/libgcc_s.so.1 (0xb7c9e000) |
40 |
> libc.so.6 => /lib/libc.so.6 (0xb7ac9000) |
41 |
> /lib/ld-linux.so.2 (0xb7fba000) |
42 |
> libm.so.6 => /lib/libm.so.6 (0xb79cf000) |
43 |
> |
44 |
> It could, for example, download a binary somewhere under the current |
45 |
> user and that would get executed by /usr/lib/firefox/firefox. |
46 |
> |
47 |
> |
48 |
> On 11/12/20 9:51 AM, Andreas Fink wrote: |
49 |
>> Hmm, interesting that it shows not the full path on one machine. This |
50 |
>> should always show you the full path: |
51 |
>> for p in `pgrep firefox` ; do ls -lh /proc/${p}/exe ; done |
52 |
>> |
53 |
>> You could also check with the following command what will be executed: |
54 |
>> which firefox |
55 |
>> Use `which -a firefox` to see all possible binaries that could be found |
56 |
>> in $PATH. |
57 |
>> The default is that /usr/bin/firefox is a bash script that would start |
58 |
>> the real firefox binary at some point. |
59 |
>> |
60 |
>> To list all packages that are installed matching firefox you could use |
61 |
>> qlist -Iv firefox |
62 |
>> qlist is part of the app-portage/portage-utils package. |
63 |
>> |
64 |
>> Maybe that will help to see what is actually running on your system and |
65 |
>> where it is installed. |
66 |
>> |
67 |
>> |
68 |
>> |
69 |
>> On Thu, 12 Nov 2020 |
70 |
>> 09:19:51 +0100 n952162<n952162@×××.de> wrote: |
71 |
>> |
72 |
>>> Ah, that is a good point ... assuming there's not an suid-updater |
73 |
>>> squirreled away somewhere. I'm pretty sure that I've run firefox (lots) |
74 |
>>> since last rebuilding it on the machine in question. |
75 |
>>> |
76 |
>>> Your test is good, but yields new questions: |
77 |
>>> |
78 |
>>> - machine 1: |
79 |
>>> |
80 |
>>> $ pgrep -a firefox |
81 |
>>> *2829 /usr/lib64/firefox/firefox --name firefox -P default* |
82 |
>>> |
83 |
>>> $ pgrep -V |
84 |
>>> pgrep from procps-ng 3.3.16 |
85 |
>>> |
86 |
>>> - machine 2 (with automatic update): |
87 |
>>> |
88 |
>>> $ pgrep -a firefox |
89 |
>>> *6355 firefox* |
90 |
>>> |
91 |
>>> $ pgrep -V |
92 |
>>> pgrep from procps-ng 3.3.16 |
93 |
>>> |
94 |
>>> In both cases, I start by just invoking "firefox" (no aliases) |
95 |
>>> |
96 |
>>> |
97 |
>>> |
98 |
>>> On 11/12/20 8:28 AM, Andreas Fink wrote: |
99 |
>>>> On Thu, 12 Nov 2020 07:55:18 +0100 |
100 |
>>>> n952162<n952162@×××.de> wrote: |
101 |
>>>> |
102 |
>>>>> I was just informed by firefox on one of my gentoo machines that firefox |
103 |
>>>>> has updated, I need to restart. |
104 |
>>>>> |
105 |
>>>>> I no longer find an option to disable automatic update. Is there no hope? |
106 |
>>>>> |
107 |
>>>>> And do I have to go through another 18 hour firefox emerge to get rid of |
108 |
>>>>> their "update"? Or is their binary sitting somewhere different from |
109 |
>>>>> "our" binary? |
110 |
>>>>> |
111 |
>>>>> Oh! Can I just remove their binary and do a resume-emerge? |
112 |
>>>>> |
113 |
>>>>> |
114 |
>>>> When firefox is updated via emerge while it is still running, this |
115 |
>>>> update is recognised by the running instance and it will tell you that |
116 |
>>>> firefox was updated and needs a restart. No automatic update happened |
117 |
>>>> as you assume, it was all done by the package manager. |
118 |
>>>> If you insist, you can check the binary that is currently running, and |
119 |
>>>> you will most certainly find out that it is not writeable by your user |
120 |
>>>> account, i.e. not by the user that is running firefox: |
121 |
>>>> pgrep -a firefox |
122 |
>>>> |
123 |
>>>> Cheers |
124 |
>>>> Andreas |
125 |
>>>> |