Installer scans entire home directory when uninstalling, and potentially DELETES many things.

Bug #1797854 reported by Luke Plant
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HPLIP
New
Undecided
Unassigned

Bug Description

I was installing HPLIP 3.18.9, downloaded from https://developers.hp.com/hp-linux-imaging-and-printing/gethplip

It detected a previous installation:

    DEPENDENCY AND CONFLICT RESOLUTION
    ----------------------------------
    HPLIP-3.16.3 exists, this may conflict with the new one being installed.
    Do you want to ('i'= Remove and Install*, 'q'= Quit)? :

This was despite the fact that I had uninstalled the previous version (from Linux Mint packages, it seems that left behind /etc/hp/hplip.conf )

I entered "i" the default, because there is no other way to continue, and the installer then appeared to do nothing for a long time (30 minutes plus) while doing a huge amount of disk activity, to the point I eventually quit it and even had to reboot my computer because it was taking forever to do anything (like all my applications were swapped out to disk).

I read the source, to find out what was going on, and came across this under the uninstallation section installer/core_installer.py line 2109, `uninstall` method:

        # removing .hplip directory
        cmd = 'find /home -name .hplip'
        if checkSudo:
            cmd = self.passwordObj.getAuthCmd() % cmd

        status, output = utils.run(cmd, self.passwordObj)
        if output is not None:
            for p in output.splitlines():
                if p.find("find:") != -1:
                    continue

                utils.remove(p, self.passwordObj, checkSudo)

This 'find' searches through every single director and every file in /home looking for one called `.hplip`. This is going to take an extremely long time on computers that have lots of files in the home directory, like mine. Further it is very unnecessary. It should only be looking for directories (e.g. `find -type d`), and you probably only need to go 2 levels deep to find them.

Further, it will potentially find **and delete** files that should not be deleted. For example, suppose I back up lots of folders, including my `.hplip` folder, to another location within my home folder. This directory will also be found and deleted by the above method. It will also delete other files from the `.hplip` folder that the user may have put there or are still wanted (e.g. hp-doctor.log files).

Any functionality that deletes files should be extremely conservative about where it even looks, and this code does the opposite.

The code also doesn't check the return value of `find` (the status value), which is terrible practice and could further result in wrong files being deleted. For example if `find` is killed and sends truncated output. This is why in Python we use exceptions

It also relies on parsing the output of `find`, which is pretty bad practice.

All of this could be vastly improved by doing just the following instead:

    find /home -mindepth 2 -maxdepth 3 -type f -path '/home/*/.hplip/hplip.conf' -delete

Also, just discovered - your base/utils.py 'remove' utility used by this code is HORRIFICALLY BUGGY AND WILL DELETE LOTS OF FILES INCORRECTLY. Specifically, it builds up shell commands using string concatenation (you should NEVER do this), and applies no escaping, so it basically does this:

    "rm -rf " + path

This will result in wrong files deleted if "path" has a space in it, and other problems (e.g. potential shell execution). This function needs to be rewritten!

In this case, suppose I had copied my `.hplip` file to "/home/myuser/docs backups" and I also have a "/home/myuser/docs" folder. The above code will now end up generating the following command:

    sudo rm -rf /home/myuser/docs backups/.iplip

which will delete my entire 'docs' folder (and not delete the '.iplip' folder, because it's at the wrong path!).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.