What is the each command's different merit between su and sudo?

[Captain Cookie]

At a BSD discussion board,
I know this thing that
some BSD users prefer su command.


I know the su command permits
the user become one like the superuser
until inputting the exit command.


The su and sudo command,
I want to each own merits and demerits!

[malspa]

Seriously, your best bet is to type something like su vs sudo in a web search engine and then start reading. You'll find tons of info on this topic.

[yancek]

The Ubuntu site has documentation on this and also includes Advantages/Disadvantages of using sudo so that would be your best place to start.

https://help.ubuntu.com/community/RootSudo

[TheFu]

man su
man sudo

It is all about the options, timeframe, which password is needed, security, groups, and flexibility.
If you want to allow someone to run 1 command with exactly x, y, z options and nothing else, then su doesn't allow that. sudo does.
If you want to change the current userid into joesuser because you are joesuser to access some of your files while using a terminal window on a workstation someone else is using, then sudo won't allow that. Only su - joesuser will work.

In a typical environment today, sudo provides all the capabilities that any home user would need, plus logging of all sudo run commands, so sudo would be the less complex choice. Plus, sudoedit is the best, safest, way I know to edit system files. Every time I see some article somewhere with sudo gedit I cringe a little. Doing that can break a system, if the userid running it hadn't already used gedit before WITHOUT sudo. Actually, this applies to almost any GUI program and sudo or su. In general, don't use either with GUI programs is the best advice. Sure, there are exceptions and techniques to get around the issues caused, but noob-users need to learn much more BEFORE those exceptions can make sense.

[kevdog]

My only take on the matter is I once found a problem when working with acme.sh when install let's encrypt certificates. The process would work when run under the su user. With sudo -- the process totally flopped. I filed a bug and never heard back. All this told me was the process isn't interchangeable for some reason.

[TheFu]

My only take on the matter is I once found a problem when working with acme.sh when install let's encrypt certificates. The process would work when run under the su user. With sudo -- the process totally flopped. I filed a bug and never heard back. All this told me was the process isn't interchangeable for some reason.

I use acme.sh too. sudo works with it, just requires the --force option for acme.sh. The idea that someone can install certs to be used on a web server, but not have elevated privileges is just wrong. Exactly how do they expect certs to be deployed without root? My only guess is they expect people to be on hosted, shared, web servers where they control certs but not apache.

Exactly how should I deploy a cert without root, here?

/etc/nginx/ssl/blog.jdpfu.com$ ll
total 20
drwxr-xr-x  2 root root 4096 Jun  6  2019 .
drwxr-xr-x 14 root root 4096 Jun 11  2019 ..
-rw-r--r--  1 root root 1907 Mar  3 13:00 cert.pem
-rw-r--r--  1 root root 3555 Mar  3 13:00 fullchain.pem
-rw-------  1 root root 1675 Mar  3 13:00 key.pem

Then restart/reload nginx without root?
How?

[Tadaen_Sylvermane]

For a personal perspective I prefer sudo. I like temporary escalation vs potential full time. That being said where Ubuntu is concerned anyone in the sudo group is effectively capable of anything as root. I'm not sure if that extends to other distros use of sudo. Sudo can be tailored for specific commands via configuration. Su is just su with no real control except keeping the password secret.

[TheFu]

Many people don't know that elevating for root isn't the only purpose for these commands. They are useful to change to other userids on the system. Linux, like all Unix systems, is multi-user from the ground up. Processes run under different userid constantly. Not all are either root nor our personal accounts. To manage those processes, we need the ability to become the other userid from time to time.

su              ==  sudo -s   # keep current env
su -            ==  sudo -i   # get new login env for the target userid
su -l www-data  ==  sudo -u www-data

But the real difference is which password gets typed in.
With sudo, it is the current userid's password.
With su, it is the target userid's password (unless you are already root).

So changing to the www-data userid, is 1-step easier using sudo than the 2-steps su requires.

[kevdog]

I use acme.sh too. sudo works with it, just requires the --force option for acme.sh.

Well that's just ducky. Using the --force option isn't ideal since its possible to overwrite things without warning.

Is it possible to activate the su user on Ubuntu? I know there are security warnings about this, however how dangerous could this be when BSD distributions have the su user installed by default. Sometimes I don't understand why decisions like these are made.

[TheFu]

Well that's just ducky. Using the --force option isn't ideal since its possible to overwrite things without warning.

Is it possible to activate the su user on Ubuntu? I know there are security warnings about this, however how dangerous could this be when BSD distributions have the su user installed by default. Sometimes I don't understand why decisions like these are made.

I prefer the sudo method. Fewer passwords to remember. Logging of commands. Plus we can switch to any user needed using sudo, so there really isn't any need for su or su - .

su user already works in the normal, expected, way. It is only for the root userid where it doesn't work. It is an artifact that root doesn't have a password on ubuntu. Nothing else.

Lots of Linux distros don't for the use of sudo like Ubuntu does. All the RHEL-based releases use su and a root account. Sadly, they enable remote root logins too, which is a terrible security failure almost always. There are a few other security reasons for the root account to only be accessible using sudo. Best for the uninformed to stick with sudo. Enabling direct root access has many negative side-effects that are better avoided.

As for acme.sh --force option overwriting things. That's why we have daily, automatic, versioned, backups that are "pulled", not "pushed". Right?!!! Something gets overwritten that breaks anything, just put the files back from the backup last night. 10 seconds of our time. It isn't like someone running a website, using HTTPS, wouldn't have backups. No way that could happen. /s