5 ms·

Ubuntu is known to break things, quite often, last one that comes to my mind was the sudo behaviour: On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote:

Ubuntu is known to break things, quite often, last one that comes to my mind was the sudo behaviour: On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote: > in Ubuntu, sudo retains the calling user's $HOME > > this is different from upstream sudo as well as all other UNIXes and > even the sudo documentation we provide. Should we remove our custom > patch that adds this behavior? Ubuntu is diverging.

tankenmate 4y ago
Wow, that is a surprise. Personally I've never hit it because I use "sudo su -".
- stefantalpalaru 4y ago
  > I use "sudo su -" You can simplify that to "sudo -i".
- cuillevel3 4y ago
  Isn't that identical to 'sudo -i'?
  - RealStickman_ 4y ago
    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 4y ago
      sudo -i and sudo -s also give you a root shell. "sudo su" is a tautology that's unnecessary is almost all cases.
      - yrro 4y ago
        $ 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 4y ago
        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 4y ago
        It's how I've trained myself to avoid 'sudo su -' - by removing my user's ability to use sudo to run su ;)
  - folmar 4y ago
    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.
- Eleison23 4y ago
  [dead]
cuillevel3 4y ago
Well, when Ubuntu was first released 18 years ago, it was the first big distribution without any open ports in the default installation and no root password. Of course there were hardening guides for Debian, which you could use to shut down the fingerd daemon and the ftp server and get rid of the global administrator account. Linux distributions had so many remotely exploitable bugs, that whole books were written about them. (Windows was still worse) Other distros slowly started to adapt the "secure by default" policy and came up with different approaches. OpenSUSE for example still uses the root password for sudo. The patch to /etc/sudoers is massive. I wouldn't expect sudo to behave the same across distros, there is a lot of history to it.
ur-whale 4y ago
> Ubuntu is known to break things, quite often, Indeed. Try and install 22.04 on a server that has two exactly identical NVME drives, you're very likely going to be in for a very interesting adventure involving a strange beast called 'multipath' devices. It was so bad I had to switch back to the legacy text installer for 20.04.
- withinboredom 4y ago
  Disabling multi path is pretty easy. That being said, months of strange errors and mount issues took a really long time to discover that that was the issue.
  - ur-whale 4y ago
    > Disabling multi path is pretty easy. At install time? All my attempts have failed in the following fashion: . I boot the text only installer . Once it runs I switch to a shell . I edit the python code of subiquity / curtin to rip out anything that has to do with mutlipath . I disable all systemd shite related to multipath . I kill the installer (and systemd restarts it) . When I get to partioning, I finally see my NVME devices instead of the weird multipath stuff . I create a raid-0 partition on them . The installer then fails miserably Care to share your recipe?
    - withinboredom 4y ago
      Put ``` blacklist { devnode "^sd[a-z0-9]+" } ``` In /etc/multipath.conf (modify for nvme as needed)

tankenmate 4y ago

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

stefantalpalaru 4y ago
> I use "sudo su -" You can simplify that to "sudo -i".
cuillevel3 4y ago
Isn't that identical to 'sudo -i'?
- RealStickman_ 4y ago
  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 4y ago
    sudo -i and sudo -s also give you a root shell. "sudo su" is a tautology that's unnecessary is almost all cases.
    - yrro 4y ago
      $ 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 4y ago
        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 4y ago
        It's how I've trained myself to avoid 'sudo su -' - by removing my user's ability to use sudo to run su ;)
- folmar 4y ago
  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.
Eleison23 4y ago
[dead]

cuillevel3 4y ago

Well, when Ubuntu was first released 18 years ago, it was the first big distribution without any open ports in the default installation and no root password. Of course there were hardening guides for Debian, which you could use to shut down the fingerd daemon and the ftp server and get rid of the global administrator account. Linux distributions had so many remotely exploitable bugs, that whole books were written about them. (Windows was still worse) Other distros slowly started to adapt the "secure by default" policy and came up with different approaches. OpenSUSE for example still uses the root password for sudo. The patch to /etc/sudoers is massive. I wouldn't expect sudo to behave the same across distros, there is a lot of history to it.

ur-whale 4y ago

> Ubuntu is known to break things, quite often, Indeed. Try and install 22.04 on a server that has two exactly identical NVME drives, you're very likely going to be in for a very interesting adventure involving a strange beast called 'multipath' devices. It was so bad I had to switch back to the legacy text installer for 20.04.

withinboredom 4y ago
Disabling multi path is pretty easy. That being said, months of strange errors and mount issues took a really long time to discover that that was the issue.
- ur-whale 4y ago
  > Disabling multi path is pretty easy. At install time? All my attempts have failed in the following fashion: . I boot the text only installer . Once it runs I switch to a shell . I edit the python code of subiquity / curtin to rip out anything that has to do with mutlipath . I disable all systemd shite related to multipath . I kill the installer (and systemd restarts it) . When I get to partioning, I finally see my NVME devices instead of the weird multipath stuff . I create a raid-0 partition on them . The installer then fails miserably Care to share your recipe?
  - withinboredom 4y ago
    Put ``` blacklist { devnode "^sd[a-z0-9]+" } ``` In /etc/multipath.conf (modify for nvme as needed)