Update to ‘polkit’ and ‘libpolkit’ today.

Modern Linux computers, that have a considerable GUI, also have a feature called ‘polkit’. The purpose of this feature is not hard to understand. There exist certain operations which require ‘root’ privileges on a Linux computer, but actual users run Graphical User Interfaces, in ‘user mode’, i.e, without elevated privileges. Usually, Linux users want to be able to do such things as to install and update packages, which requires ‘root’ privileges, but want to be able to do so using the GUI. And so the way the feature ‘polkit’ is organized, there exists a daemon running as user ‘root’, which can among other things update packages, and there exists another daemon running as the specific user, which makes requests to the ‘root’ polkit daemon, to update packages. The root daemon carries out the requested action.

This arrangement may seem to make more sense for Ubuntu, where there is no such thing in a pronounced way, as ‘root’, as there is under Debian. But even some Debian setups have partial Ubuntu installs running, and many Debian users also like the ease, of being able to install a package, just by clicking on it, and then, by convincing the ‘root’ polkit daemon, that the user in question is privileged enough to do so.

Well today, my two Debian / Jessie systems, which I name ‘Phoenix’ and ‘Klystron’, have received routine updates to the polkit packages themselves. But the rather unbalanced, immediate result of this is, that on both these computers, the user-space daemon is still running the old binary, from before the update, while a new ‘root’ daemon has been launched, as part of the update. The two versions of ‘polkit’ running on both these computers, may or may not continue to be compatible with each other.

If they should turn out to be incompatible, then in the very near future I’ll need to reboot both computers as well, which could therefore also lead to brief downtime for this blog.

I’m keeping my fingers crossed, that the new service may be running in a way that remained compatible, with the old client.

Dirk

Both the Linux-laptop I name ‘Klystron’, and the server of this Web-site, this server being named ‘Phoenix’, received a major update this evening. On ‘Phoenix’, a total of 78 packages needed to be updated, including a Kernel-Update, and a Graphics-Driver Update. This collective update effectively converted both computers from Debian 8.7 to Debian 8.8 systems. And both updates appear to have succeeded, at first glance without breaking anything.

However, this was an update that required a reboot for ‘Phoenix’, even though this is my Web-server, and so my site was also down briefly, from approximately 20h40 until 20h50.

I am happy to say however, that ‘Phoenix’ had been running for 58 days straight, without requiring any reboot whatsoever until tonight.

Oh, but I must disappoint some of my readers with the fact that performing these updates also required I restart my ‘memcached‘ service, which means that pages or postings the readers like to visit most often will be a bit slower to fetch, until this server-side caching is replenished.

Dirk

WordFence

One of the facts which I have written about before, is that my blog is set up in a slightly customized way, with core PHP files that come from the Debian package manager, and which do not have permission bits set, so that the Web-server can write to them, but also with add-ons – aka plugin-ins – with permission bits set so that the server can. This latter detail is a great convenience for me, because it allows me to install plug-ins from WordPress.org, as well as to install updates to those, via means that are simple for me to operate.

What I have also written, is that this makes my overall security good, but not perfect. Theoretically, there could be a corrupted plug-in available directly from WordPress.org – even though in general, they do their best to vet those – and which I could install to my blog, without knowing it. Further, even if the plug-in contains no dirty code visible to WordPress.org, the way some of them work might depend on a Web-service from their author, and then that URL could be running some sort of suspicious scripts, let us say on yet another server.

And so a reasonable question to ask might be, of what use WordFence can be in my case. One of the types of scans which this security add-on performs, is a check of all my core files, against what the versions are with WordPress.org, not with Debian. And then this scan reports 58 deviations to me, without analyzing them, just because Debian has slightly different core-file-versions. It also checks my entire plug-in directory, scans all the plug-ins, etc.. But in reality, WordFence never reported any kind of anomaly in my plug-ins, because those are the WordPress.org versions.