On: Ubuntu 22.04 LTS servers and phased apt updates

[tankenmate]

Wow, that is a surprise. Personally I've never hit it because I use "sudo su -".

[cuillevel3 → tankenmate]

Isn't that identical to 'sudo -i'?

[folmar → cuillevel3]

No, `sudo su -` gives you a shell resembling one you would get when logging in interactively as root, while `sudo -i` applies some of its configuration. Which is not always well suited for interactive uses to put it lightly. For example PATH is set to something smaller than I would like.

[RealStickman_ → cuillevel3]

It gives you a pretty similar result in the end. From my understanding, with 'sudo -i', you're still using sudo itself to run commands as root (or any other specified user).

'sudo su -' instead executes the 'su -' command, giving you a root shell, as a superuser with 'sudo'. If you left the 'sudo' out, you'd have to type the root password.

[tremon → RealStickman_]

sudo -i and sudo -s also give you a root shell. "sudo su" is a tautology that's unnecessary is almost all cases.

[yrro → tremon]

    $ sudo -l
    [...]
    
    User yrro may run the following commands on fw33748-02:
        (ALL : ALL) ALL
        (ALL : ALL) !/usr/bin/sudo, !/usr/bin/su, !/bin/su

So

    $ sudo su -
    Sorry, user yrro is not allowed to execute '/usr/bin/su -' as root on fw33748-02.example.qq.

[tremon → yrro]

I'm not sure what point you're trying to make, but:

  $ sudo /bin/sh -c su -

It's never useful to deny certain commands to a user if that user is allowed to open a shell. Any shell. So you probably want to change that first line to

  (ALL : ALL) NOEXEC: ALL

and provide a whitelist for all tools that do spawn children as part of their normal operation (such as apt, dpkg, and probably half of all unix tooling).

[yrro → tremon]

It's how I've trained myself to avoid 'sudo su -' - by removing my user's ability to use sudo to run su ;)

[stefantalpalaru → tankenmate]

> I use "sudo su -"

You can simplify that to "sudo -i".