This looks basically ok to me. More below:
On 3/10/25 8:50 AM, Hefee via tor-dev wrote:
Hey,
in Debian we want to enable mutli-arch support for torsocks. To be able to run
different binaries of different archs.
We already splitted libtorsocks into own package, so you can now install
e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386
But the torsocks script loads the libtorsocks by full path, so
torsocks wget will fail, as it loads the amd64 variant only.
ldconfig has this nice feature to find the correct library, if you only add the
name and that the library is in default search dir or you add a conf file in /
etc/ld.so.conf.d/.
Maybe we could be a *little* more explicit and use a full path
incorporating `${LIB}`? From ld.so(8):
```
In several places, the dynamic linker expands dynamic string tokens:
o In the environment variables LD_LIBRARY_PATH, LD_PRELOAD, and
LD_AUDIT,
...
$LIB (or equivalently ${LIB})
This expands to lib or lib64 depending on the
architecture (e.g., on x86-64, it expands to
lib64 and on x86-32, it expands to lib).
```
This might head off some other weird corner cases (like some other
`libtorsocks` ending up earlier in the library search path) and maybe
give a stronger hint about what's going wrong in the error message you
note below where the right library can't be found.
Using just the libname makes the "safty" check `! -e "$SHLIB"` fail, as
$SHLIB, is only the libname in our case.
Can you have a look at the patch[1], if you think it is safe to ship this?
[1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/
patches/0004-Make-torsocks-multi-arch-foreign-compatible.patch
The issue I see is this:
If arch from executable and the corresponding libtorsocks is not installed,
only a Error is printed, but still the executable is executed without routing
trough tor. The disabled check in torsocks could somehow catch this, if we
would knew the arch of the executable in advanced correctly (which we don't,
so far). If we can make sure, that LD_PRELOAD would stop executing, if the
library cannot be found.
e.g. I install libtorsocks:amd64 and wget:i386 I get:
$wget -O- -4 icanhazip.com
XX.230.187.XX
$ torsocks wget -O- -4 icanhazip.com
ERROR: ld.so: object 'libtorsocks.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
[...]
XX.230.187.XX
[...]
(installing libtorsocks:i386 fixes this)
On the other side, this does not got worse; currently torsocks will print
a different error see #902792 but still execute the binary without tor. So this
safety check doesn't help here (and btw. installing libtorsocks:i386 does not
fix this issue by itself you also need to call /usr/bin/i386-linux-gnu-
torsocks).
#902792 https://bugs.debian.org/cgi-bin/902792
This is an unfortunate failure mode, but yeah at least not worse than
the current state.
I was thinking about whether the torsocks script could try harder to
detect this case, e.g. by itself checking what arch binary is being run
and whether the corresponding library exists, but this would add a fair
bit of complexity and would still miss cases where the target binary
spawns more processes, possibly of different archs (e.g. `torsocks bash
-c "wget ..."`)
Regards,
hefee
_______________________________________________
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
-Jim
_______________________________________________
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
