Fedy’s installation of Brackets bricks your Fedora installation

I wanted to give Fedy a try yesterday, specifically to install the **Brackets **code editor designed for web developers. I’m pretty lazy when it comes to install external packages (from the Brackets.io’s homepage it looked like only a DEB file was available) and after asking a few friends who made heavy use of Fedy in the past about its stability and credibility I went ahead and followed the provided instructions to set it up.

The interface was pretty straightforward and installing Brackets was as easy and clicking on the relevant button. Before starting the installation I gave a fast look around to the various bash scripts used by Fedy to install the package I wanted and yeah, I admit I did not pay enough attention to a few lines of the code and went ahead with the installation.

After hacking a bit with Brackets I decided it was time for me to head to bed but shutting down my laptop surprisingly returned various errors related to Systemd’s journal not being able to shutdown properly. I then tried to reboot the machine and found out the laptop was totally not bootable anymore.

The error it was reported at boot (Systemd Journal not being able to start properly) was pretty strange and after looking around the web I couldn’t find any other report about similar failures. I then started digging around with a friend and made the following guesses:

1. The root partition was running out of space (just 70M left), I then cleaned it a bit and rebooted with no luck. My first guess was /tmp going out of space when Systemd tries to populate it at boot time.
2. I checked yum history to find out what Fedy could have taken in, but nothing relevant was found given Fedy does not install RPM packages on its own, it usually retrieves a tarball (or in my case a DEB package) and installs it by extracting / cping the content
3. I turned SELinux to Permissive and rebooted the machine, surprise, the machine was bootable again

The next move was running a restorecon -r -v / against the root partition, the result was awful: the whole /usr‘s context was turned into usr_tmp_t. Digging around the code for the Brackets installer the following code was found:

mkdir -p "${file%.*}"
ar p "$file" "data.tar.gz" | tar -C "${file%.*}" -xzf -
cp -af ${file%.*}/* "/"

<br>

And previously:

get_file_quiet "http://download.brackets.io/" "brackets.htm"
get=$(cat "brackets.htm" | tr ' ' '\n' | grep -o "file.cfm?platform=LINUX${arch}&build=[0-9]*" | head -n 1 | sed -e 's/^/http:\/\/download.brackets.io\//')
file="brackets-LINUX.deb"

<br>

So what the installer was doing is:

1. Downloading the DEB file from the Brackets website
2. Extracting its content to /tmp/fedy and copying the contents of the data.tar.gz tarball in place

A tree view of the data.tar.gz file:

.
|-- opt
| `-- brackets
`-- usr
|-- bin
`-- share

<br>

Copying the extracted content of the data.tar.gz tarball to the target directories will do exactly one thing: it will overwrite the SELinux context of your /usr, /bin, /share directories breaking your system. I would advise everyone to NOT make use of Fedy for installing the Brackets editor until the issue has been fixed. Honestly speaking I didn’t have time / willingness to check other bash scripts but something nasty might be found there as well. Generally I would never recommend to install anything on your system without making use of an RPM package. Lesson learned for me to never trust such tools in the future on my local system.

The issue seems it was reported already one month ago, we added our report to the same issue. You can track it at https://github.com/satya164/fedy/issues/79.

Resources:

1. Faulty bash script: https://github.com/satya164/fedy/blob/master/plugins/soft/adobe_brackets.sh
2. Why usr_tmp_t gets added as /usr‘s context: https://github.com/satya164/fedy/blob/master/fedy#L26.