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