The pitfalls of some post-install scripts

Lots of users run Proxmox suite of products with no support license and as long as they understand the caveats of freely available packages, there is nothing wrong with that. A major “post-install” chore no to forget is setting up the no-subscription repositories - otherwise users will be left with no updates whatsoever. Many also opt to look for a solution to get rid of the infamous “No valid subscription” notice popup, also dubbed as a nag - for a reason.

Security risk

Having to deal with chores like this is somewhat inexplicable given that Proxmox distribute their suite under a FREE license - which grants everyone freedom to modify it as they please. This simply means users WILL take advantage of third-party solutions and are then often left in the dark what those actually do to their otherwise stock install. In turn, Proxmox open up their unpaid user base to third-party associated security risks over something that could have been resolved with a simple acknowledgment checkbox.

What not to do

This post exists to encourage better understanding of the system and what a user runs on it. The last thing one wants to end up with is having stealth third-party recurrent scripts on their system that they do not even comprehend.

Notably, whatever a user ends up running on a Proxmox host is running under the root privileges due to the architecture of Proxmox suite of products.

Issues with standalone scripts

There is a major caveat to using a simple script for a problem at hand here: effects of it will NOT persist, changes would get overwritten during upgrades from official repositories. Any “one-off” script that does NOT have this drawback uses its “single run” to install something onto the system that then runs recurrently. There goes the popular perception of a mere script being less intrusive to the system then a more complex solution.

The popular post-install script

Merely due to number of inquiries - NOT because it does something particularly worse than others - we will have a look at the now community maintained post-install script found under the misc category and delve right into its source on GitHub.  

We will ONLY focus on one of its parts, namely: removing the ’no-subscription’ popup. It can be found below a line: msg_info "Disabling subscription nag"

There’s the code of our interest - which we will dissect:

echo "DPkg::Post-Invoke { \"...\"; };" >/etc/apt/apt.conf.d/no-nag-script
apt --reinstall install proxmox-widget-toolkit &>/dev/null

And the inner part (...) was (reformatted - all from that single line, escaping NOT retained):

dpkg -V proxmox-widget-toolkit | grep -q '/proxmoxlib\.js$'

if [ $? -eq 1 ]; then {
    echo 'Removing subscription nag from UI...';

    sed -i '/.*data\.status.*{/{s/\!//;s/active/NoMoreNagging/}' \
        /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js;
}; fi

APT hook

The first part adds a DPkg::Post-Invoke like into a file under /etc/apt/apt.conf.d/ - this belongs to APT hooks that are then run (as per the rule) virtually every time APT runs on the system, for whichever reason, over all packages. Such scripts (the content) have to be scrutinised as they are basically living on on the system and run under root privileges, regularly.

Following addition of this inner (recurrent) script onto the system, ir proceeds to (once) reinstall original a Proxmox package - this might look counter-intuitive, but it actually relies on the (now installed) recurrent script to do its work already on the APT run (i.e. hence the hook designation), i.e. the reinstall will be subject to the inner script already.

sed command

The inner script - this will be run regularly, e.g. after updates - checks result of dpkg -V, i.e. integrity of the same Proxmox package, more specifically it will find out whether a file named proxmoxlib.js has been tampered with (compared with the stock version that comes with the package).

The conditional if statement only executes the sed inside if the package is intact (stock). This is a wide assumption - that nothing else is e.g. patching the same file - as otherwise it would not do anything. The idea was to only execute the patching when the target file has changed, but unfortunately the APT hooks were absolutely not designed for this kind of problem and so there’s no knowing what exactly APT was altering on the system - hence the conditional check. The script runs every time APT runs, but only shows the announcement when it is about to patch anything.

JavaScript patched

The actual sed run is beyond the scope of this post, but it is a method of replacing strings through the use of so-called regular expressions, i.e. the file proxmoxlib.js will have its content altered on one specific line, changing it (< out, > in):

< 			.data.status.toLowerCase() !== 'active') {
---
> 			.data.status.toLowerCase() == 'NoMoreNagging') {

This affects the JavaScript component of Proxmox - a condition within - more of the surrounding JavaScript code can be seen in a separate post here regarding the no subscription notice removal - by a different method. A mere reformatting of the underlying target file might deem this regular expression ineffective, corrupt the JavaScript code or worse - change the logic without bringing in any obviously corrupt syntax and in an unintended piece of code.

A better way

These were some of the gotchas that one faces when running random, unreviewed scripts that could leave behind unexpecte skeletons in the wardrobe. What is left to cover is a proposal on how to approach the same issues - by all means very valid to a majority of users - in a more systematic way.