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:
- 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.
- 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
- 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:
|
1 2 3 |
mkdir -p "${file%.*}" ar p "$file" "data.tar.gz" | tar -C "${file%.*}" -xzf - cp -af ${file%.*}/* "/" |
And previously:
|
1 2 3 |
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" |
So what the installer was doing is:
- Downloading the DEB file from the Brackets website
- 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:
|
1 2 3 4 5 6 |
. |-- opt | `-- brackets `-- usr |-- bin `-- share |
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:
- Faulty bash script: https://github.com/satya164/fedy/blob/master/plugins/soft/adobe_brackets.sh
- Why usr_tmp_t gets added as /usr‘s context: https://github.com/satya164/fedy/blob/master/fedy#L26.
0
0
1
0
0
“it usually retrieves a tarball (or in my case a DEB package) and installs it by extracting / cping the content”
“Usually” will be a bit rude when it was done for only once.
Anyways, humans make mistakes, and we learn eventually and fix them. About trusting such tools, it all depends on you, because your friend did some mistake in the past due to ignorance and then corrects it when he knows, you don’t stop trusting him.
Anyways, may be have a look at other scripts and let me know if there are more issues. Thanks.
@Satya: don’t take my post as a personal attack, Fedora comes with SELinux turned on on Enforcing mode by default, that means your scripts should make sure a default installation is not bricked like it happened in this case.
I’m not saying people should not trust Fedy anymore, I’m saying you should test your scripts on a default / stock setup which includes, as said above, SELinux on Enforcing mode and cope with that.
I’m sure I’m not the only one that runs Fedora with SELinux set as Enforcing and that probably means the Brackets installation broke several other installations.
Thanks for the prompt answer and fix. (assigning default_t to the various files is not the greatest solution though given each of the directories where the files have been installed do have their own context, (i.e /usr/bin/brackets should go under the bin_t context) but at least the system won’t break and the application will still be able to run correctly)
@andrea Yeah. I understand, and I’ll test it with SELinux enabled for future releases.
Yeah, I know, assigning default_t to every file is not good. But since there’ll be lot of files, it was the quickest fix I found. In future I’ll try to do something to assign correct labels automatically.
Thanks for your time to report the issue. It helps a lot.
+1 vote for end-user programs being installed in a single-isolated-sandboxed directory. Any modifications of existing directories (/usr/bin/… etc) should be strictly controlled by the OS packet manager, and ideally should be symlinks to things inside said single-isolated-sandboxed directory.
@DDD: +1, nothing should bypass the package manager of the distribution for changes that involve modifications of system-directories.
And I fully agree that custom / external applications should only run on isolated-sandboxed environments to prevent any breakage that could result in the system being not bootable anymore.
Hopefully even the Brackets upstream will sooner or later release an RPM which should avoid the need of manually installing the packages by hand. I’d have used alien in this case though so at least an RPM was being generated and used. (with all the checks on the installed files RPM itself would have run to prevent the breakage to happen)
I used https://github.com/jgillich/brackets-rpm which worked out OK.
Hello, I’m here searching for an easy and straight forward way to remove Brackets when previously installed with fedy.
I want to remove it since it depends on chromium, which I have no interest in installing it. I.e. it is useless to me.