Livepatch has fixed kernel vulnerabilities. Or not???
Bo Berglund
bo.berglund at gmail.com
Wed Apr 19 16:09:22 UTC 2023
On Tue, 18 Apr 2023 11:11:49 -0500, Keith <keithw at caramail.com> wrote:
>On 4/18/23 1:27 AM, Bo Berglund wrote:
>
>[snipped]
>
>>>
>>> Remove cached snap files in /var/lib/snapd/cache
>>> Not directory, just files.
>> there are 7 files in there all with very long names like this:
>> 3aca523f924d16583217c9b029f8c626972012f9c6fab26b4cb987ec64b50e273751f8a7be35328d5bd6404d4db0af2d
>>
>> and sudo rm /var/lib/snapd/cache/* just shows an error message:
>> rm: cannot remove '/var/lib/snapd/cache/*': No such file or directory
>
>I think that is a glob expansion issue. Do "sudo -s" and then try to
>remove the files as root.
>
>>
>> When I specify one of the files by adding the start of the name:
>> sudo ls -la /var/lib/snapd/cache/3*
>> ls: cannot access '/var/lib/snapd/cache/3*': No such file or directory
>>
>> Are these strange files the ones you refer to as "cached snap files"?
>
>Yes, these are cached snap squashfs archives. The purpose in removing
>them is to make sure that when re-installing a snap, snapd downloads the
>snap archive from the website rather than using a cached copy. Normally,
>if there has been an update to a particular snap, snapd will download
>the new version instead using the cached version. I just wanted to be
>sure we were dealing with a non-cached version.
>>
>> Had top stop here since I could not follow your instructions for removing....
>> But I looked at the commands and found some I do not really understand:
>>
>>> Manually install canonical-livepatch snap
>>> $ sudo snap install canonical-livepatch
>>>
>>> Enable canonical-livepatch
>>> $ sudo pro enable livepatch
>>>
>>> Check ~/snap/canonical-livepatch
>>> Is there a symbolic link "current" pointing to the revision of the
>>> canonical-livepatch snap (196 for the latest/stable)?
>>> If not, make one.
>>> Do the same for /root/snap/canonical-livepatch
>>
>> Please explain these commands, I do not understand how to make it manually...
>> What is "revision of the canonical-livepatch snap"?
>> Is that a file somewhere and is it named "196"???
>> Also what do you mean by "do the same"? >
>
>The revision of a snap is that part of the version number that that
>snapd presents to the user to handle and distinguish between installed
>snaps of the same release. Among other things it distinguishes between
>which snap is enabled/disabled. The 202 revision update was installed on
>my system after my previous post. So now the livepatch config/cache
>directories in ~/snap and /root/snap have a symbolic link "current"
>pointing to 202 to indicate that that is the currently enabled revision
>of the snap.
>
># ls -l /root/snap/canonical-livepatch
>total 12
>drwxr-xr-x 2 root root 4096 Feb 3 16:07 196
>drwxr-xr-x 2 root root 4096 Feb 3 16:07 202
>drwxr-xr-x 2 root root 4096 Feb 3 16:07 common
>lrwxrwxrwx 1 root root 3 Apr 14 09:47 current -> 202
>
>
>$ snap list --all canonical-livepatch
>Name Version Rev Tracking Publisher Notes
>canonical-livepatch 10.5.3 196 latest/stable canonical? disabled
>canonical-livepatch 10.5.4 202 latest/stable canonical? -
>
>Note in the livepatch example there has been a increment of the minor
>version number so it's a new version of the snap, but that's not always
>the case. For example,
>
>$ snap list --all qt5-core20
>Name Version Rev Tracking Publisher Notes
>qt5-core20 20.04 14 latest/stable keshavnrj? disabled
>qt5-core20 20.04 15 latest/stable keshavnrj? -
>
>qt5-core20 is a snap of the QT5 stack needed by some QT based snaps.
>Same version but different revision. The latest revision, 15, is enabled.
>
>I didn't think about this at the time, but since you're using 20.04, you
>may be using a livepatch snap from a different channel that what 22.04
>uses. "Snap list canonical-livepatch" will tell for sure. The Rev number
>is what should appear in the canonical-livepatch directories in ~/snap
>and /root/snap.
>
>My hunch as to why canonical-livepatch thinks you need to upgrade the
>kernel and restart the system is that there is possibly some file that
>when present signals the livepatch service of the restart state and that
>after a completed kernel patch and reboot, this file should have been
>removed but for some reason wasn't. So there might be some stale file
>present somewhere. I don't know if this correct, it's just a guess.
>Clearing out the leftover canonical-livepatch directories in /root/snap
>and ~/snap after uninstalling the livepatch snap and then letting them
>get created again after re-installing livepatch hopefully would have
>gotten rid of the stale file if it had existed.
>
>To keep this to one message, I'll respond to your 2nd post here:
>
>> sudo ls -la /home/bosse/snap/canonical-livepatch
>> ls: cannot access '/home/bosse/snap/canonical-livepatch': No such file or
>> directory
>
>Shouldn't be necessary to use sudo here if /home/bosse is your logged-in
>user's home directory. Is there a canonical-livepatch directory in
>/root/snap? On my system, I went through all the steps I advised in my
>message and those directories were recreated in both locations. Perhaps
>running the command "canonical-livepatch status" both as the login user
>and root will cause them to be recreated.
>
>I'm afraid I'm all out of ideas if you've re-installed the livepatch
>snap but are still getting that motd message about needing a restart
>even after you've already rebooted a number of times. I'd recommend
>filing a bug at the link Oliver provided in his last response to you.
>I'd also check https://forum.snapcraft.io and post an inquiry there.
>Someone may be able to walk you through a debug session of what's
>happening and/or provide more accurate information on how livepatch
>determines when a system needs a kernel update and restart.
>
>--
>Keith
So now I have tested a few of the items mentioned above and gotten this:
$ sudo ls -l /root/snap/canonical-livepatch
total 12
drwxr-xr-x 2 root root 4096 mar 12 08:26 196
drwxr-xr-x 2 root root 4096 mar 12 08:26 202
drwxr-xr-x 2 root root 4096 mar 12 08:26 common
lrwxrwxrwx 1 root root 3 apr 14 17:54 current -> 202
$ ls -la ~/snap/canonical-livepatch/
total 20
drwxr-xr-x 5 bosse bosse 4096 apr 14 17:54 .
drwx------ 3 bosse bosse 4096 mar 12 08:26 ..
drwxr-xr-x 2 bosse bosse 4096 mar 12 08:26 196
drwxr-xr-x 2 bosse bosse 4096 mar 12 08:26 202
drwxr-xr-x 2 bosse bosse 4096 mar 12 08:26 common
lrwxrwxrwx 1 bosse bosse 3 apr 14 17:54 current -> 202
So there *is* now a canonical-livepatch dir and inside a symlink in both places!
$ sudo ls -la /var/lib/snapd/
total 164
drwxr-xr-x 24 root root 4096 apr 19 17:34 .
drwxr-xr-x 75 root root 4096 jan 5 2022 ..
drwxr-xr-x 4 root root 4096 jan 5 2022 apparmor
drwxr-xr-x 4 root root 4096 jan 5 2022 assertions
drwxr-xr-x 2 root root 4096 jan 5 2022 auto-import
drwx------ 2 root root 4096 apr 11 23:39 cache
drwx------ 2 root root 4096 mar 12 08:26 cookie
drwxr-xr-x 4 root root 4096 jan 5 2022 dbus-1
drwxr-xr-x 4 root root 4096 jan 5 2022 desktop
drwxr-xr-x 3 root root 4096 jan 5 2022 device
drwxr-xr-x 2 root root 4096 jan 5 2022 environment
drwxr-xr-x 2 root root 4096 maj 23 2022 features
drwxr-xr-x 2 root root 4096 jan 5 2022 firstboot
drwxr-xr-x 2 root root 4096 jan 5 2022 hostfs
drwxr-xr-x 2 root root 4096 mar 12 08:26 inhibit
drwxr-xr-x 6 root root 4096 jan 5 2022 lib
drwxr-xr-x 2 root root 4096 apr 16 04:59 mount
drwxr-xr-x 3 root root 4096 jan 5 2022 seccomp
drwxr-xr-x 4 root root 4096 jan 5 2022 seed
drwxr-xr-x 2 root root 4096 apr 17 04:44 sequence
drwxr-xr-x 3 root root 4096 apr 17 04:44 snaps
drwx------ 2 root root 4096 jan 5 2022 snapshots
drwxr-xr-x 3 root root 4096 jan 5 2022 ssl
-rw------- 1 root root 60701 apr 19 17:34 state.json
-rw-r--r-- 1 root root 0 apr 4 2022 state.lock
-rw-r--r-- 1 root root 629 mar 21 01:14 system-key
-rw-r--r-- 1 root root 10 jan 10 13:23 system-params
d--x--x--x 2 root root 4096 jan 5 2022 void
$ sudo ls -la /var/lib/snapd/cache/
total 888856
drwx------ 2 root root 4096 apr 11 23:39 .
drwxr-xr-x 24 root root 4096 apr 19 17:34 ..
-rw------- 1 root root 64770048 okt 7 2021
0570d23d6f7a25be85dff79984bf00c2d60fb51cc7af6833315ba24f5d8f399cabb2456bf9189a8d44ece20922d612d0
-rw------- 1 root root 254115840 okt 7 2021
2eaaf63b7a8ee5928398901040ff4b24221b1162908459f1acd1ad9632f7266565e0900cc34bcc3fbbf77a02240e5a78
-rw------- 2 root root 10031104 apr 11 23:39
5aed3f827d0acf21320166f484a8317e32af100e024f636334d6ac53cbc9675d07232bf694941dbbdd3a1a6eb3afe09d
-rw------- 1 root root 53522432 jan 8 2021
790c957edf90fba117e0a4838c80759bd9298ad8d96bee76b63d7444403419b006b073c69447eb37726e83e0a84daf8b
-rw------- 2 root root 4096 okt 7 2021
8692b00c936f6f46e9063a493de7294ad8285a6c7ddd9de8281f0138c72a9d6186f95004732a840e8d655bac34009732
-rw------- 1 root root 434470912 okt 4 2022
c91419f0d2e8df66f175d19cc637710b064f3fd44bd04e577e4795b49ffd5c650abeb32caf2ec4d5da915dbe9ba19801
-rw------- 1 root root 73834496 okt 4 2022
f8a6ceb7a7ed81b4f725d2a37facdc5e7c6a9373f1a137ccdd25b1a6757b613002de29186bc640402f7a4d1778c20d85
-rw------- 1 root root 9396224 mar 12 08:26
fa732a23552ff31171ff43aa9ac78dc3e4e49b470cda7e83efc627879d597f1c977589d87e23fd309873550460c49138
-rw------- 1 root root 10027008 apr 5 23:19
fadbee6b873b51bcaed23b73303c39ad7198e5c7a0d826300ba39923ec89f25200337ac377abcd002cd3bea3ef004deb
And here we have the cached files again owned by root.
I guess I should go back to your original steps and perform them again noa that
I more clearly know what is being done...
I.e. uninstall canonical-livepatch and delete all cache files, even though they
might not belong to canonical-livepatch?
I assume they are not needed but are a means of speeding up updates from locally
cached files. If not existing then a download will be done, right???
Still having the reboot message on login but I have not yet rebooted. Such an
action will disturb two remote locations abroad which connect back home...
Must be manually reset locally.
I probably have a window open tomorrow morning though.
--
Bo Berglund
Developer in Sweden
More information about the ubuntu-users
mailing list