Please don't port philosophy with code!
One of my pet peeves is Linux installers for proprietary software requiring root permissions.
Last time, Adobe got me into rant mode by requiring root not only to install the Adobe Air runtime, but to install any Adobe Air based application as well. This time it's Abbyy – makers of the famous Finereader OCR software.
Before I start explaining what's so bad about requiring root for installing, I want to give a short disclaimer:
I'm not against non-Open Source software running on Linux. It isn't my first choice for sure, but sometimes there are no alternatives available and I'm happy about every company providing a Linux port of their software. Even when it is closed source.
This is also not against Abbyy. They just happen to be the most recent example I encountered. On the contrary – I'm a fan of Finereader, Abbyy is using DokuWiki at ocr4linux and they made a generous donation to the project. I like Abbyy.
What's the problem?
Why not requiring root for installing the software? After all my distribution's package manager needs root, too?
There are two major problems with root-only installers.
The first is security. Having a strict separation between the superuser and the normal users is an important security measurement. Especially on multiuser machines. If run an
rm -rf I mess up my own stuff only. The system keeps running and all other users are unaffected as well. If the tool I install in my home has virus, only my files are at risk.
However security isn't the main problem here. It is not that I think the software I'm about to install has any malicious intends. Most companies do not intentionally screw their customer's systems.
The bigger problem is loss of control. I'm running Linux because it is a system I am in control of. I know how things interact. I know where programs are installed and I know my package manager is taking care of putting everything to the right place. There is no yearly reinstalling to take care of all the cruft that accumulated over time of installing and uninstalling software as many people are used from Windows.
Giving a proprietary, closed source installer access to my whole system, takes away that control. I do not know what it will do. Where things will be placed, what files will be touched. When something stops working because of it I have no idea where to look. Additionally all distributions do things a little bit different, a third party installer is most likely to make false assumptions anyway.
Again, I'm happy to be able to run this closed source software on my system. It gives me more choice of using the right tools. All I ask is vendors should not port Windows philosophy with porting the source code.
How bad is it?
Maybe I'm exxagerating the problem? Let's have a look at what Abbyy's installer for FineReader Engine 8.0 CLI for Linux does.
The download comes as a single file called
abbyyocr-8.7002.42.tar.gz. It contains a PDF guide and a single shellscript with some archive data appended. Basically a self extracting archive. Completely superfluous – providing a .tgz would be just fine. If you want to make it comfortable provide some .deb and .rpm files additionally.
Running this file will extract the data to /tmp and run an installer shell script. This script immediately aborts if you're not root. Bad!
Luckily the archive can be extracted to have a look inside:
./abbyyocr.run --noexec --target unpacked/
Looking at the
install.sh, you'll see that it starts with displaying an EULA and copying all data to
/opt/ABBYOCR/. Optionally it puts the binaries to
/usr/local/bin. So far so good.
Then it starts to get ugly:
# Registering of shared libraries if [ -z `cat /etc/ld.so.conf | grep $ABBYYOCR_DIR/ABBYYOCR` ]; then echo -e "$ABBYYOCR_DIR/ABBYYOCR\n" >> /etc/ld.so.conf ldconfig fi export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:$LD_LIBRARY_PATH
It modifies my library configuration path and reconfigures an environment variable. The former is one of those things I'd definitively like to be informed about. The latter is a bit strange as it affects only the current shell anyway – and why
/usr/local/lib when we installed to
The script then continues by calling another script that starts the license activation process. You need to activate the tool not only with a license key but through some Internet activation. Another case of porting Windows philosophy, but I'm willing to let that one slip . Let's have a look at this script then.
The script checks if the curl utility is installed – if not it will ask if you'd like to install it. If you agree, curl will build and installed to
This is a really bad idea. Most distributions look for programs in
/usr/local/bin first. So if you forget about this binary, you will not be able to run a version installed from your package manager later. At least the installer asks about it.
Next, the license activation tool is run. This is a closed source binary. Running it through strace reveals that it creates a file in
/var/lib/frengine/.elf/erf.vsf before running curl or preparing the email activation. I have no idea what is in that file, but I guess it contains some information about the local hardware that is used to do the actual activation.
Yes that's a “hidden” directory inside your system's
/var/lib directory1). Why? I understand that this information needs to be gathered and stored to implement an activation mechanism. However this “secrecy” makes me uncomfortable to trust the rest of the software.
Quick summary: the installer
- modifies a system library path without notice
- might install an outdated curl to
- installs a “secret” file without notice
All this wouldn't be necessary. Just let me install the whole bunch of files into a single directory of my choosing and I'm happy. I'm not asking about open sourcing your software or throwing away activation and copy protection stuff 2).
All I ask is, don't mess with my system and don't ask me to trust you more than you trust me!