7 Fixed a a doubled word :)
source | link

With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well. So, so that what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well. So what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well, so that what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

6 fixed grammar
source | link

With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well, so that. So what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

The main difference between sudo bash and sudo -s is is that -s is shorter and lets you pass commands to execute in your user's default shell in a couple of ways:

With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well, so that what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

The main difference between sudo bash and sudo -s is is that -s is shorter and lets you pass commands to execute in your user's default shell in a couple of ways:

With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well. So what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

The main difference between sudo bash and sudo -s is that -s is shorter and lets you pass commands to execute in your user's default shell in a couple of ways:

5 assorted minor tweaks
source | link
  • Commands you run through sudo execute as the target user — root by default, but changeable with -u — but it logs the commands you run through it, tagging them with your username so blame can be assigned afterward. :)

  • sudo is very flexible. You can limit the commands a given user or group of users are allowed to run, for example. With su, it's all or nothing.

    This feature is typically used to define roles. For instance, you could define a "backups" group allowed to run dump and tar, each of which needs root access to properly back up the system disk.

    I mention this here because it means you can give someone sudo privileges without giving them sudo -s or sudo bash abilities. They have only the permissions they need to do their job, whereas with su they have run of the entire system. You have to be careful with this, though: if you give someone the ability to say sudo vi, for example, they can shell out of vi and have effectively the same power as with sudo -s.

  • Because it takes the sudoer's password instead of the root password, sudo isolates permission between multiple sudoers.

    This solves an administrative problem with su, which is that when the root password changes, all those who had to know it to use su had to be told. sudo allows the sudoers' passwords to change independently. In fact, it is common to password-lock the root user's account, so that on a system with sudo to force all sysadmin tasks have to be done via sudo. In a large organization with many trusted sudoers, this means when one of the sysadmins leaves, you don't have to change the root password and distribute it to those admins who remain.

  1. You can say sudo -s some-command which runs some-command under your shell, as if you had said. It's basically shorthand for sudo $SHELL -c some-command.  

  2. You can instead pass the commands to the shell's standard input, like sudo -s < my-shell-script. You could use this with a heredoc to send several commands to a single sudo call, avoiding the need to type sudo repeatedly.

MostBoth of those behaviors are optional. Far more commonly, you don't do either: you just give -s alone, with no argument, and don't pipe anything into the standard input of sudo, so it just runs your user's shell interactively. In that mode, it differs from sudo bash in that it might run a different shell than bash, since it looks first in the SHELL environment variable, and then if that is unset, at your user's login shell setting, typically in /etc/passwd.

You might say, "If they can modify PAGER, they can modify PATH, and then they can just substitute an evil sudo program," but someone sufficiently paranoid can say /usr/bin/sudo -s/bin/bash to avoid that trap. You're probably not so paranoid that you also avoid the traps in all the other susceptible environment variables, though. Did you also remember to check EDITOR, for example, before running any VCS command? Thus sudo -i.

  • Commands you run through sudo execute as the target user — root by default, but changeable with -u — but it logs the commands you run through it, tagging them with your username so blame can be assigned afterward. :)

  • sudo is very flexible. You can limit the commands a given user or group of users are allowed to run, for example. With su, it's all or nothing.

    This feature is typically used to define roles. For instance, you could define a "backups" group allowed to run dump and tar, each of which needs root access to properly back up the system disk.

    I mention this here because it means you can give someone sudo privileges without giving them sudo -s or sudo bash abilities. They have only the permissions they need to do their job, whereas with su they have run of the entire system. You have to be careful with this, though: if you give someone the ability to say sudo vi, for example, they can shell out of vi and have effectively the same power as with sudo -s.

  • Because it takes the sudoer's password instead of the root password, sudo isolates permission between multiple sudoers.

    This solves an administrative problem with su, which is that when the root password changes, all those who had to know it to use su had to be told. sudo allows the sudoers' passwords to change independently. In fact, it is common to password-lock the root user's account, so that all sysadmin tasks have to be done via sudo. In a large organization with many trusted sudoers, this means when one of the sysadmins leaves, you don't have to change the root password and distribute it to those admins who remain.

  1. You can say sudo -s some-command which runs some-command under your shell, as if you had said $SHELL -c some-command.  

  2. You can instead pass the commands to the shell's standard input, like sudo -s < my-shell-script.

Most commonly, you don't do either: you just give -s alone, with no argument, and don't pipe anything into the standard input of sudo, so it just runs your user's shell. In that mode, it differs from sudo bash in that it might run a different shell than bash, since it looks first in the SHELL environment variable, and then if that is unset, at your user's login shell setting, typically in /etc/passwd.

You might say, "If they can modify PAGER, they can modify PATH," but someone sufficiently paranoid can say /usr/bin/sudo -s to avoid that trap. You're probably not so paranoid that you also avoid the traps in all the other susceptible environment variables, though. Did you also remember to check EDITOR, for example, before running any VCS command? Thus sudo -i.

  • Commands you run through sudo execute as the target user — root by default, but changeable with -u — but it logs the commands you run through it, tagging them with your username so blame can be assigned afterward. :)

  • sudo is very flexible. You can limit the commands a given user or group of users are allowed to run, for example. With su, it's all or nothing.

    This feature is typically used to define roles. For instance, you could define a "backups" group allowed to run dump and tar, each of which needs root access to properly back up the system disk.

    I mention this here because it means you can give someone sudo privileges without giving them sudo -s or sudo bash abilities. They have only the permissions they need to do their job, whereas with su they have run of the entire system. You have to be careful with this, though: if you give someone the ability to say sudo vi, for example, they can shell out of vi and have effectively the same power as with sudo -s.

  • Because it takes the sudoer's password instead of the root password, sudo isolates permission between multiple sudoers.

    This solves an administrative problem with su, which is that when the root password changes, all those who had to know it to use su had to be told. sudo allows the sudoers' passwords to change independently. In fact, it is common to password-lock the root user's account on a system with sudo to force all sysadmin tasks to be done via sudo. In a large organization with many trusted sudoers, this means when one of the sysadmins leaves, you don't have to change the root password and distribute it to those admins who remain.

  1. You can say sudo -s some-command which runs some-command under your shell. It's basically shorthand for sudo $SHELL -c some-command.

  2. You can instead pass the commands to the shell's standard input, like sudo -s < my-shell-script. You could use this with a heredoc to send several commands to a single sudo call, avoiding the need to type sudo repeatedly.

Both of those behaviors are optional. Far more commonly, you give -s alone, so it just runs your user's shell interactively. In that mode, it differs from sudo bash in that it might run a different shell than bash, since it looks first in the SHELL environment variable, and then if that is unset, at your user's login shell setting, typically in /etc/passwd.

You might say, "If they can modify PAGER, they can modify PATH, and then they can just substitute an evil sudo program," but someone sufficiently paranoid can say /usr/bin/sudo /bin/bash to avoid that trap. You're probably not so paranoid that you also avoid the traps in all the other susceptible environment variables, though. Did you also remember to check EDITOR, for example, before running any VCS command? Thus sudo -i.

4 Clarified the spoofability problem of sudo -s; explained the list-of-commands features of sudo -i and -s
source | link
3 clarified some of the spoofability concerns of sudo -s, and the issues of target user vs root
source | link
2 clarified some of the spoofability concerns of sudo -s
source | link
1
source | link