So, /usr/lib/firefox/firefox runs, and is writable only by root. But it
can't be that the full firefox functionality gets executed in 239364 bytes!
$ type firefox
firefox is /usr/bin/firefox
$ which -a firefox
/usr/bin/firefox
$ ll /usr/bin/firefox
lrwxrwxrwx 1 root root 24 Nov 16 2019 /usr/bin/firefox ->
/usr/lib/firefox/firefox
$ ll /usr/lib/firefox/firefox
-rwxr-xr-x 1 root root 239364 Nov 16 2019 /usr/lib/firefox/firefox
$ file /usr/lib/firefox/firefox
/usr/lib/firefox/firefox: ELF 32-bit LSB pie executable, Intel
80386, version 1 (SYSV), dynamically linked, interpreter
/lib/ld-linux.so.2, for GNU/Linux 3.2.0, stripped
I tried this but don't see anything that looks promising:
$ ldd /usr/lib/firefox/firefox
linux-gate.so.1 (0xb7fb9000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7f3f000)
libdl.so.2 => /lib/libdl.so.2 (0xb7f3a000)
libstdc++.so.6 =>
/usr/lib/gcc/i686-pc-linux-gnu/9.3.0/libstdc++.so.6 (0xb7cbc000)
libgcc_s.so.1 =>
/usr/lib/gcc/i686-pc-linux-gnu/9.3.0/libgcc_s.so.1 (0xb7c9e000)
libc.so.6 => /lib/libc.so.6 (0xb7ac9000)
/lib/ld-linux.so.2 (0xb7fba000)
libm.so.6 => /lib/libm.so.6 (0xb79cf000)
It could, for example, download a binary somewhere under the current
user and that would get executed by /usr/lib/firefox/firefox.
On 11/12/20 9:51 AM, Andreas Fink wrote:
Hmm, interesting that it shows not the full path on one machine. This
should always show you the full path:
for p in `pgrep firefox` ; do ls -lh /proc/${p}/exe ; done
You could also check with the following command what will be executed:
which firefox
Use `which -a firefox` to see all possible binaries that could be found
in $PATH.
The default is that /usr/bin/firefox is a bash script that would start
the real firefox binary at some point.
To list all packages that are installed matching firefox you could use
qlist -Iv firefox
qlist is part of the app-portage/portage-utils package.
Maybe that will help to see what is actually running on your system and
where it is installed.
On Thu, 12 Nov 2020
09:19:51 +0100 n952162 <n952...@web.de> wrote:
Ah, that is a good point ... assuming there's not an suid-updater
squirreled away somewhere. I'm pretty sure that I've run firefox (lots)
since last rebuilding it on the machine in question.
Your test is good, but yields new questions:
- machine 1:
$ pgrep -a firefox
*2829 /usr/lib64/firefox/firefox --name firefox -P default*
$ pgrep -V
pgrep from procps-ng 3.3.16
- machine 2 (with automatic update):
$ pgrep -a firefox
*6355 firefox*
$ pgrep -V
pgrep from procps-ng 3.3.16
In both cases, I start by just invoking "firefox" (no aliases)
On 11/12/20 8:28 AM, Andreas Fink wrote:
On Thu, 12 Nov 2020 07:55:18 +0100
n952162 <n952...@web.de> wrote:
I was just informed by firefox on one of my gentoo machines that firefox
has updated, I need to restart.
I no longer find an option to disable automatic update. Is there no hope?
And do I have to go through another 18 hour firefox emerge to get rid of
their "update"? Or is their binary sitting somewhere different from
"our" binary?
Oh! Can I just remove their binary and do a resume-emerge?
When firefox is updated via emerge while it is still running, this
update is recognised by the running instance and it will tell you that
firefox was updated and needs a restart. No automatic update happened
as you assume, it was all done by the package manager.
If you insist, you can check the binary that is currently running, and
you will most certainly find out that it is not writeable by your user
account, i.e. not by the user that is running firefox:
pgrep -a firefox
Cheers
Andreas
