Ubuntu applies security fixes for all versions back to 14.04

Ubuntu has issued a batch of updates that cover the default as well as the AWS and KVM flavours for the current short-term release 21.10, both the original 5.04 and OEM 5.14 builds for the current 20.04 LTS release, as well as 18.04, and, surprisingly, even 16.04 and 14.04. While kernel releases trickle out all the time, the …

[Tom7]

Soooooo.... are the fixes important?

[DoContra]

From the box to the right of the article, all fixes seem to be medium severity local privilege escalations and some backported bluetooth fixes for exploitable bugs (which I assume require bluetooth hardware)

[Snake]

RE: are they important

Following the links in the story:

- both 21.10 release, and 20.04 / 5.14 LTS builds contains Medium-level CVE's

- however, 20.04 LTS / 5.04 build contains a High-level CVE, CVE-2022-0492

etc.

So yes, I would say that they should be applied as soon as possible.

[Chris Gray 1]

Don't use &&

Since "&&" allows the processes to all run at the same time, methinks you *must* use ";" to separate them - you want them to run sequentially, not all at once. Even if there is some magic locking that is done, there is no guarantee which command starts first.

[Wempy]

Re: Don't use &&

no, `&` allows them to run concurrently (in the background) `&&` will run the next one only when the preceeding one finishes with an exit code of zero.

[Chris Gray 1]

Re: Don't use &&

Ok, now I'm *really* embarassed. Sigh. I don't do shell programming much. Heck, its even consistent with what the operators do in C programming (which I'm sure is quite deliberate).

[katrinab]

Re: Don't use &&

&& runs the next command if the previous one returns a 0 exit code

|| runs the next command if the previous one returns a non-zero exit code

So for example

pgrep foo || foo

would run foo if it isn't already running

pgrep foo && bar

would run bar only if foo is running

I use the first example a lot in cron scripts where I don't want to run a new instance if the previous one is still running.

[original_rwg]

If it ain't broke - upgrade anyway :)

[Dr Paul Taylor]

Ain't broke, don't fix it

Ubuntu snap zoom-client wasn't broke on 25 January. Then it updated itself automatically and now its audio is broke. And there seems to be no old versions available to which to revert, even though snap provides a machanism for this.

[DoContra]

Your scheduled bit pedantry whenever shell commands are mentioned

When using sudo (and not using relative paths), it's a good idea to pass -H (set $HOME to the target user's home directory -- root's home in this case) as this can potentially apply small to moderate borking to the non-root user's config files (the one I've had and seen was permission problems on vim's per-user files); for this use (calling apt/aptitude) it shouldn't be a problem but...

From the fine article's commands:

sudo -s

would become

sudo -Hs

PD: The advice to wait for the LTS.1 release is so good, Ubuntu forces it on you: when configured to upgrade only to the next LTS, Ubuntu's updater will not show the update until sometime after the .1 version releases (or you call the distro upgrader manually with the -d option).

PPD: Most internet guides will either have multiple sudo invocations (one for each command), or will do something like sudo bash -c "list; of; commands". I'm not educated enough to discuss the relative merits of either of these three options, but personally I find this article's approach the most convenient by far, so that's what I use.

[Tom7]

Re: Your scheduled bit pedantry whenever shell commands are mentioned

The usual reason for multiple sudos rather than sudo -s is that it leaves visible traces of what you've done in the system log files, where sudo -s just records that someone has become root but doesn't show what they've done.

[Tom Chiverton 1]

Re: Your scheduled bit pedantry whenever shell commands are mentioned

Or set up unattended-upgrades and forget about it.

WFM

[Anonymous Coward]

Re: Your scheduled bit pedantry whenever shell commands are mentioned

Both sudo -s and sudo -i set $HOME to /root

Try it!

[AndrewV]

I'd take that last advice one step further and add "apt update && apt full-upgrade -y && apt autoremove -y && apt purge && apt clean" as an alias in .bashrc

[Anonymous Coward]

Not my way?

So far I am seeing no value here? I have always booted, then waited out unattended-upgr then did these commands - which usually have results after the unattended-upgr has run:

sudo apt update

sudo apt full-upgrade -y

sudo apt autoremove -y

sudo apt autoclean -y

With the new commands I am not seeing any added updating, and snaps are already updated?!?

[Tom 7]

Re: Not my way?

1) You may find you have security updates set to automatically install re:unattended-upgr?

2) You may be pointing at alternative (country based?) repositories that have not been updated as yet.

I hope its 1.

https://www.cyberciti.biz/faq/how-to-set-up-automatic-updates-for-ubuntu-linux-18-04/ may help you go full tonto on it.

[Anonymous Coward]

Re: Not my way?

I am using the US and I think 1 is in play. It is also from what I can see that full-upgrade updates the snaps. One thing I did learn is I tried my 21.04 images which are no longer getting updates. The snap refresh "worked" and updated several snap packages, thought the rest of the commands found no updates. I think this qualifies as a "bug" since 21.04 otherwise no longer gets updates?!?