su vs sudo -s vs sudo -i vs sudo bash
What is the difference between the following commands:
su
sudo -s
sudo -i
sudo bash
I know for su
I need to know the root password, and for sudo
I have to be in the sudoers
file, but once executed what is difference?
I know there is a difference between su
and sudo -s
because my home directory is /root
after I execute su
, but my home directory is still /home/myname
after sudo -s
. But I suspect this is just a symptom of an underlying difference that I'm missing.
sudo su
add a comment |
What is the difference between the following commands:
su
sudo -s
sudo -i
sudo bash
I know for su
I need to know the root password, and for sudo
I have to be in the sudoers
file, but once executed what is difference?
I know there is a difference between su
and sudo -s
because my home directory is /root
after I execute su
, but my home directory is still /home/myname
after sudo -s
. But I suspect this is just a symptom of an underlying difference that I'm missing.
sudo su
3
I prefer to usesudo su -
This way you don't need the root password, and the-
makes sure the home directory is set right.
– Jens Timmerman
Apr 26 '13 at 10:34
See also Which is the safest way to get root privileges: sudo, su or login?
– Gilles
Aug 21 '15 at 22:22
add a comment |
What is the difference between the following commands:
su
sudo -s
sudo -i
sudo bash
I know for su
I need to know the root password, and for sudo
I have to be in the sudoers
file, but once executed what is difference?
I know there is a difference between su
and sudo -s
because my home directory is /root
after I execute su
, but my home directory is still /home/myname
after sudo -s
. But I suspect this is just a symptom of an underlying difference that I'm missing.
sudo su
What is the difference between the following commands:
su
sudo -s
sudo -i
sudo bash
I know for su
I need to know the root password, and for sudo
I have to be in the sudoers
file, but once executed what is difference?
I know there is a difference between su
and sudo -s
because my home directory is /root
after I execute su
, but my home directory is still /home/myname
after sudo -s
. But I suspect this is just a symptom of an underlying difference that I'm missing.
sudo su
sudo su
edited Oct 11 '15 at 7:27
techraf
4,153102139
4,153102139
asked Mar 29 '12 at 19:27
Snitse
6662713
6662713
3
I prefer to usesudo su -
This way you don't need the root password, and the-
makes sure the home directory is set right.
– Jens Timmerman
Apr 26 '13 at 10:34
See also Which is the safest way to get root privileges: sudo, su or login?
– Gilles
Aug 21 '15 at 22:22
add a comment |
3
I prefer to usesudo su -
This way you don't need the root password, and the-
makes sure the home directory is set right.
– Jens Timmerman
Apr 26 '13 at 10:34
See also Which is the safest way to get root privileges: sudo, su or login?
– Gilles
Aug 21 '15 at 22:22
3
3
I prefer to use
sudo su -
This way you don't need the root password, and the -
makes sure the home directory is set right.– Jens Timmerman
Apr 26 '13 at 10:34
I prefer to use
sudo su -
This way you don't need the root password, and the -
makes sure the home directory is set right.– Jens Timmerman
Apr 26 '13 at 10:34
See also Which is the safest way to get root privileges: sudo, su or login?
– Gilles
Aug 21 '15 at 22:22
See also Which is the safest way to get root privileges: sudo, su or login?
– Gilles
Aug 21 '15 at 22:22
add a comment |
3 Answers
3
active
oldest
votes
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.
Things are very different with sudo
:
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. Withsu
, 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
andtar
, 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 themsudo -s
orsudo bash
abilities. They have only the permissions they need to do their job, whereas withsu
they have run of the entire system. You have to be careful with this, though: if you give someone the ability to saysudo vi
, for example, they can shell out ofvi
and have effectively the same power as withsudo -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 usesu
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 withsudo
to force all sysadmin tasks to be done viasudo
. 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.
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:
You can say
sudo -s some-command
which runssome-command
under your shell. It's basically shorthand forsudo $SHELL -c some-command
.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 singlesudo
call, avoiding the need to typesudo
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
.
The shell run by sudo -s
inherits your current user environment. If what you actually want is a clean environment, like you get just after login, what you want instead is sudo -i
, a relatively recent addition to sudo
. Roughly speaking, sudo -i
is to sudo -s
as su -
is to su
: it resets all but a few key environment variables and sends you back to your user's home directory. If you don't also give it commands to run under that shell via standard input or sudo -i some-command
, it will run that shell as an interactive login shell, so your user's shell startup scripts (e.g. .bash_profile
) get run again.
All of this makes sudo -i
considerably more secure than sudo -s
. Why? Because if someone can modify your environment before sudo -s
, they could cause unintended commands to be executed. The most obvious case is modifying SHELL
, but it can also happen less directly, such as via PAGER
if you say man foo
while under sudo -s
.
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
.
Because sudo -i
also changes your working directory to your user's home directory, you might still want to use sudo -s
for those situations where you know you want to remain in the same directory you were cd
'd into when you ran sudo
. It's still safer to sudo -i
and cd
back to where you were, though.
2
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
10
@crisron: From withinvi
, type:sh
and hit Enter. Now you're in a sub-shell, with all the privileges of thevi
process that spawned that shell. Ifvi
is running with root privileges, so will the shell. Or, you can run something other than a shell via:!cmd
, read output from a command into the edit buffer via:r !cmd
, etc. If all those are locked down,Makefile
targets are shell scripts, and Vim has the:make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.
– Warren Young
Oct 20 '14 at 5:57
1
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
1
@lesmana: I've addressed that in an edit; basically, thePATH
isn't the only problem.
– Warren Young
Aug 2 '15 at 23:39
5
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
|
show 5 more comments
From an ubuntuforums post I made a while ago:
Consider the following experiment:
applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
root@ion:/home/applic# exit
exit
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s
Here are the differences I found:
With sudo -s
:
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
With sudo su
:
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Notice the difference in $HOME
. Being root and having $HOME
set to the normal user's home can cause problems. For example, if you run a graphical app, the normal user's ~/.Xauthority
can get overwritten by root. This causes the normal user problems later on such as not being able to run certain graphical apps through cron.
To summarize:
corrupted by user's
HOME=/root uses root's PATH env vars
sudo -i Y Y[2] N
sudo -s N Y[2] Y
sudo bash N Y[2] Y
sudo su Y N[1] Y
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
probably set by/etc/environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
The bottom line is sudo -i
is the proper command to run when you want a root shell that is untainted by the user's environment.
1
How much the environment is 'tainted' depends on the configuration ofsudo
(in/etc/sudoers
and related files) as well. Configuration settings such asalways_set_home
,env_reset
,env_keep
,env_check
andenv_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.
– Curt J. Sampson
Dec 7 '17 at 11:35
add a comment |
su
(switch user or substitute user) lets you switch user. su
basically starts another shell instance with the privileges of the intended user. By default it switches you to the root
user, if we want to switch specific user we need to pass user as follows:
$ su bob # switches to bob (requires bob's password)
su -
means environment variables will be reset to root and su
means environment variables as old user.
for example: root's home directory if you use su -
or old user home directory if you use su
.
sudo (super user do) is a command-line utility that allows users to run programs with the security privileges of another user, by default is superuser i.e root
. It uses a config file /etc/sudoers
which lists which users have rights to specific actions
sudo should be read as /ˈsuːduː/. syntax sudo command
i.e. switch user and do this command.
su
is equivalent tosudo -i
and simulates a login into the root account. Your working
directory will be/root
, and it will read root's.profile
etc.sudo -s
launches a shell as root, but doesn't change your working
directory.sudo bash
wherebash
is command to run withsudo
. This command runs
bash
as a super user.- Using
sudo
can be logged everything someone does. - Using
sudo
prevents a user from having to know the root password. - Using
sudo
we can limit the commands are allowed to run.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f35338%2fsu-vs-sudo-s-vs-sudo-i-vs-sudo-bash%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Things are very different with sudo
:
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. Withsu
, 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
andtar
, 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 themsudo -s
orsudo bash
abilities. They have only the permissions they need to do their job, whereas withsu
they have run of the entire system. You have to be careful with this, though: if you give someone the ability to saysudo vi
, for example, they can shell out ofvi
and have effectively the same power as withsudo -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 usesu
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 withsudo
to force all sysadmin tasks to be done viasudo
. 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.
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:
You can say
sudo -s some-command
which runssome-command
under your shell. It's basically shorthand forsudo $SHELL -c some-command
.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 singlesudo
call, avoiding the need to typesudo
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
.
The shell run by sudo -s
inherits your current user environment. If what you actually want is a clean environment, like you get just after login, what you want instead is sudo -i
, a relatively recent addition to sudo
. Roughly speaking, sudo -i
is to sudo -s
as su -
is to su
: it resets all but a few key environment variables and sends you back to your user's home directory. If you don't also give it commands to run under that shell via standard input or sudo -i some-command
, it will run that shell as an interactive login shell, so your user's shell startup scripts (e.g. .bash_profile
) get run again.
All of this makes sudo -i
considerably more secure than sudo -s
. Why? Because if someone can modify your environment before sudo -s
, they could cause unintended commands to be executed. The most obvious case is modifying SHELL
, but it can also happen less directly, such as via PAGER
if you say man foo
while under sudo -s
.
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
.
Because sudo -i
also changes your working directory to your user's home directory, you might still want to use sudo -s
for those situations where you know you want to remain in the same directory you were cd
'd into when you ran sudo
. It's still safer to sudo -i
and cd
back to where you were, though.
2
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
10
@crisron: From withinvi
, type:sh
and hit Enter. Now you're in a sub-shell, with all the privileges of thevi
process that spawned that shell. Ifvi
is running with root privileges, so will the shell. Or, you can run something other than a shell via:!cmd
, read output from a command into the edit buffer via:r !cmd
, etc. If all those are locked down,Makefile
targets are shell scripts, and Vim has the:make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.
– Warren Young
Oct 20 '14 at 5:57
1
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
1
@lesmana: I've addressed that in an edit; basically, thePATH
isn't the only problem.
– Warren Young
Aug 2 '15 at 23:39
5
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
|
show 5 more comments
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.
Things are very different with sudo
:
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. Withsu
, 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
andtar
, 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 themsudo -s
orsudo bash
abilities. They have only the permissions they need to do their job, whereas withsu
they have run of the entire system. You have to be careful with this, though: if you give someone the ability to saysudo vi
, for example, they can shell out ofvi
and have effectively the same power as withsudo -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 usesu
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 withsudo
to force all sysadmin tasks to be done viasudo
. 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.
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:
You can say
sudo -s some-command
which runssome-command
under your shell. It's basically shorthand forsudo $SHELL -c some-command
.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 singlesudo
call, avoiding the need to typesudo
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
.
The shell run by sudo -s
inherits your current user environment. If what you actually want is a clean environment, like you get just after login, what you want instead is sudo -i
, a relatively recent addition to sudo
. Roughly speaking, sudo -i
is to sudo -s
as su -
is to su
: it resets all but a few key environment variables and sends you back to your user's home directory. If you don't also give it commands to run under that shell via standard input or sudo -i some-command
, it will run that shell as an interactive login shell, so your user's shell startup scripts (e.g. .bash_profile
) get run again.
All of this makes sudo -i
considerably more secure than sudo -s
. Why? Because if someone can modify your environment before sudo -s
, they could cause unintended commands to be executed. The most obvious case is modifying SHELL
, but it can also happen less directly, such as via PAGER
if you say man foo
while under sudo -s
.
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
.
Because sudo -i
also changes your working directory to your user's home directory, you might still want to use sudo -s
for those situations where you know you want to remain in the same directory you were cd
'd into when you ran sudo
. It's still safer to sudo -i
and cd
back to where you were, though.
2
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
10
@crisron: From withinvi
, type:sh
and hit Enter. Now you're in a sub-shell, with all the privileges of thevi
process that spawned that shell. Ifvi
is running with root privileges, so will the shell. Or, you can run something other than a shell via:!cmd
, read output from a command into the edit buffer via:r !cmd
, etc. If all those are locked down,Makefile
targets are shell scripts, and Vim has the:make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.
– Warren Young
Oct 20 '14 at 5:57
1
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
1
@lesmana: I've addressed that in an edit; basically, thePATH
isn't the only problem.
– Warren Young
Aug 2 '15 at 23:39
5
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
|
show 5 more comments
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.
Things are very different with sudo
:
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. Withsu
, 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
andtar
, 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 themsudo -s
orsudo bash
abilities. They have only the permissions they need to do their job, whereas withsu
they have run of the entire system. You have to be careful with this, though: if you give someone the ability to saysudo vi
, for example, they can shell out ofvi
and have effectively the same power as withsudo -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 usesu
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 withsudo
to force all sysadmin tasks to be done viasudo
. 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.
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:
You can say
sudo -s some-command
which runssome-command
under your shell. It's basically shorthand forsudo $SHELL -c some-command
.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 singlesudo
call, avoiding the need to typesudo
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
.
The shell run by sudo -s
inherits your current user environment. If what you actually want is a clean environment, like you get just after login, what you want instead is sudo -i
, a relatively recent addition to sudo
. Roughly speaking, sudo -i
is to sudo -s
as su -
is to su
: it resets all but a few key environment variables and sends you back to your user's home directory. If you don't also give it commands to run under that shell via standard input or sudo -i some-command
, it will run that shell as an interactive login shell, so your user's shell startup scripts (e.g. .bash_profile
) get run again.
All of this makes sudo -i
considerably more secure than sudo -s
. Why? Because if someone can modify your environment before sudo -s
, they could cause unintended commands to be executed. The most obvious case is modifying SHELL
, but it can also happen less directly, such as via PAGER
if you say man foo
while under sudo -s
.
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
.
Because sudo -i
also changes your working directory to your user's home directory, you might still want to use sudo -s
for those situations where you know you want to remain in the same directory you were cd
'd into when you ran sudo
. It's still safer to sudo -i
and cd
back to where you were, though.
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.
Things are very different with sudo
:
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. Withsu
, 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
andtar
, 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 themsudo -s
orsudo bash
abilities. They have only the permissions they need to do their job, whereas withsu
they have run of the entire system. You have to be careful with this, though: if you give someone the ability to saysudo vi
, for example, they can shell out ofvi
and have effectively the same power as withsudo -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 usesu
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 withsudo
to force all sysadmin tasks to be done viasudo
. 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.
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:
You can say
sudo -s some-command
which runssome-command
under your shell. It's basically shorthand forsudo $SHELL -c some-command
.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 singlesudo
call, avoiding the need to typesudo
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
.
The shell run by sudo -s
inherits your current user environment. If what you actually want is a clean environment, like you get just after login, what you want instead is sudo -i
, a relatively recent addition to sudo
. Roughly speaking, sudo -i
is to sudo -s
as su -
is to su
: it resets all but a few key environment variables and sends you back to your user's home directory. If you don't also give it commands to run under that shell via standard input or sudo -i some-command
, it will run that shell as an interactive login shell, so your user's shell startup scripts (e.g. .bash_profile
) get run again.
All of this makes sudo -i
considerably more secure than sudo -s
. Why? Because if someone can modify your environment before sudo -s
, they could cause unintended commands to be executed. The most obvious case is modifying SHELL
, but it can also happen less directly, such as via PAGER
if you say man foo
while under sudo -s
.
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
.
Because sudo -i
also changes your working directory to your user's home directory, you might still want to use sudo -s
for those situations where you know you want to remain in the same directory you were cd
'd into when you ran sudo
. It's still safer to sudo -i
and cd
back to where you were, though.
edited Apr 1 '17 at 16:42
answered Mar 29 '12 at 20:59
Warren Young
54.6k10142146
54.6k10142146
2
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
10
@crisron: From withinvi
, type:sh
and hit Enter. Now you're in a sub-shell, with all the privileges of thevi
process that spawned that shell. Ifvi
is running with root privileges, so will the shell. Or, you can run something other than a shell via:!cmd
, read output from a command into the edit buffer via:r !cmd
, etc. If all those are locked down,Makefile
targets are shell scripts, and Vim has the:make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.
– Warren Young
Oct 20 '14 at 5:57
1
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
1
@lesmana: I've addressed that in an edit; basically, thePATH
isn't the only problem.
– Warren Young
Aug 2 '15 at 23:39
5
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
|
show 5 more comments
2
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
10
@crisron: From withinvi
, type:sh
and hit Enter. Now you're in a sub-shell, with all the privileges of thevi
process that spawned that shell. Ifvi
is running with root privileges, so will the shell. Or, you can run something other than a shell via:!cmd
, read output from a command into the edit buffer via:r !cmd
, etc. If all those are locked down,Makefile
targets are shell scripts, and Vim has the:make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.
– Warren Young
Oct 20 '14 at 5:57
1
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
1
@lesmana: I've addressed that in an edit; basically, thePATH
isn't the only problem.
– Warren Young
Aug 2 '15 at 23:39
5
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
2
2
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
What do you mean by 'shell out of vi'?
– crisron
Oct 20 '14 at 5:01
10
10
@crisron: From within
vi
, type :sh
and hit Enter. Now you're in a sub-shell, with all the privileges of the vi
process that spawned that shell. If vi
is running with root privileges, so will the shell. Or, you can run something other than a shell via :!cmd
, read output from a command into the edit buffer via :r !cmd
, etc. If all those are locked down, Makefile
targets are shell scripts, and Vim has the :make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.– Warren Young
Oct 20 '14 at 5:57
@crisron: From within
vi
, type :sh
and hit Enter. Now you're in a sub-shell, with all the privileges of the vi
process that spawned that shell. If vi
is running with root privileges, so will the shell. Or, you can run something other than a shell via :!cmd
, read output from a command into the edit buffer via :r !cmd
, etc. If all those are locked down, Makefile
targets are shell scripts, and Vim has the :make
command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold.– Warren Young
Oct 20 '14 at 5:57
1
1
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:
/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path:
/usr/bin/sudo
– lesmana
Aug 2 '15 at 19:35
1
1
@lesmana: I've addressed that in an edit; basically, the
PATH
isn't the only problem.– Warren Young
Aug 2 '15 at 23:39
@lesmana: I've addressed that in an edit; basically, the
PATH
isn't the only problem.– Warren Young
Aug 2 '15 at 23:39
5
5
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
Great explanation; great headache reading it.
– lobi
Oct 1 '15 at 16:53
|
show 5 more comments
From an ubuntuforums post I made a while ago:
Consider the following experiment:
applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
root@ion:/home/applic# exit
exit
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s
Here are the differences I found:
With sudo -s
:
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
With sudo su
:
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Notice the difference in $HOME
. Being root and having $HOME
set to the normal user's home can cause problems. For example, if you run a graphical app, the normal user's ~/.Xauthority
can get overwritten by root. This causes the normal user problems later on such as not being able to run certain graphical apps through cron.
To summarize:
corrupted by user's
HOME=/root uses root's PATH env vars
sudo -i Y Y[2] N
sudo -s N Y[2] Y
sudo bash N Y[2] Y
sudo su Y N[1] Y
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
probably set by/etc/environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
The bottom line is sudo -i
is the proper command to run when you want a root shell that is untainted by the user's environment.
1
How much the environment is 'tainted' depends on the configuration ofsudo
(in/etc/sudoers
and related files) as well. Configuration settings such asalways_set_home
,env_reset
,env_keep
,env_check
andenv_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.
– Curt J. Sampson
Dec 7 '17 at 11:35
add a comment |
From an ubuntuforums post I made a while ago:
Consider the following experiment:
applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
root@ion:/home/applic# exit
exit
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s
Here are the differences I found:
With sudo -s
:
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
With sudo su
:
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Notice the difference in $HOME
. Being root and having $HOME
set to the normal user's home can cause problems. For example, if you run a graphical app, the normal user's ~/.Xauthority
can get overwritten by root. This causes the normal user problems later on such as not being able to run certain graphical apps through cron.
To summarize:
corrupted by user's
HOME=/root uses root's PATH env vars
sudo -i Y Y[2] N
sudo -s N Y[2] Y
sudo bash N Y[2] Y
sudo su Y N[1] Y
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
probably set by/etc/environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
The bottom line is sudo -i
is the proper command to run when you want a root shell that is untainted by the user's environment.
1
How much the environment is 'tainted' depends on the configuration ofsudo
(in/etc/sudoers
and related files) as well. Configuration settings such asalways_set_home
,env_reset
,env_keep
,env_check
andenv_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.
– Curt J. Sampson
Dec 7 '17 at 11:35
add a comment |
From an ubuntuforums post I made a while ago:
Consider the following experiment:
applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
root@ion:/home/applic# exit
exit
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s
Here are the differences I found:
With sudo -s
:
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
With sudo su
:
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Notice the difference in $HOME
. Being root and having $HOME
set to the normal user's home can cause problems. For example, if you run a graphical app, the normal user's ~/.Xauthority
can get overwritten by root. This causes the normal user problems later on such as not being able to run certain graphical apps through cron.
To summarize:
corrupted by user's
HOME=/root uses root's PATH env vars
sudo -i Y Y[2] N
sudo -s N Y[2] Y
sudo bash N Y[2] Y
sudo su Y N[1] Y
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
probably set by/etc/environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
The bottom line is sudo -i
is the proper command to run when you want a root shell that is untainted by the user's environment.
From an ubuntuforums post I made a while ago:
Consider the following experiment:
applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
root@ion:/home/applic# exit
exit
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s
Here are the differences I found:
With sudo -s
:
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
With sudo su
:
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Notice the difference in $HOME
. Being root and having $HOME
set to the normal user's home can cause problems. For example, if you run a graphical app, the normal user's ~/.Xauthority
can get overwritten by root. This causes the normal user problems later on such as not being able to run certain graphical apps through cron.
To summarize:
corrupted by user's
HOME=/root uses root's PATH env vars
sudo -i Y Y[2] N
sudo -s N Y[2] Y
sudo bash N Y[2] Y
sudo su Y N[1] Y
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
probably set by/etc/environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
The bottom line is sudo -i
is the proper command to run when you want a root shell that is untainted by the user's environment.
edited Oct 24 '15 at 21:28
muru
1
1
answered Mar 29 '12 at 20:30
unutbu
55635
55635
1
How much the environment is 'tainted' depends on the configuration ofsudo
(in/etc/sudoers
and related files) as well. Configuration settings such asalways_set_home
,env_reset
,env_keep
,env_check
andenv_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.
– Curt J. Sampson
Dec 7 '17 at 11:35
add a comment |
1
How much the environment is 'tainted' depends on the configuration ofsudo
(in/etc/sudoers
and related files) as well. Configuration settings such asalways_set_home
,env_reset
,env_keep
,env_check
andenv_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.
– Curt J. Sampson
Dec 7 '17 at 11:35
1
1
How much the environment is 'tainted' depends on the configuration of
sudo
(in /etc/sudoers
and related files) as well. Configuration settings such as always_set_home
, env_reset
, env_keep
, env_check
and env_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.– Curt J. Sampson
Dec 7 '17 at 11:35
How much the environment is 'tainted' depends on the configuration of
sudo
(in /etc/sudoers
and related files) as well. Configuration settings such as always_set_home
, env_reset
, env_keep
, env_check
and env_reset
, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.– Curt J. Sampson
Dec 7 '17 at 11:35
add a comment |
su
(switch user or substitute user) lets you switch user. su
basically starts another shell instance with the privileges of the intended user. By default it switches you to the root
user, if we want to switch specific user we need to pass user as follows:
$ su bob # switches to bob (requires bob's password)
su -
means environment variables will be reset to root and su
means environment variables as old user.
for example: root's home directory if you use su -
or old user home directory if you use su
.
sudo (super user do) is a command-line utility that allows users to run programs with the security privileges of another user, by default is superuser i.e root
. It uses a config file /etc/sudoers
which lists which users have rights to specific actions
sudo should be read as /ˈsuːduː/. syntax sudo command
i.e. switch user and do this command.
su
is equivalent tosudo -i
and simulates a login into the root account. Your working
directory will be/root
, and it will read root's.profile
etc.sudo -s
launches a shell as root, but doesn't change your working
directory.sudo bash
wherebash
is command to run withsudo
. This command runs
bash
as a super user.- Using
sudo
can be logged everything someone does. - Using
sudo
prevents a user from having to know the root password. - Using
sudo
we can limit the commands are allowed to run.
add a comment |
su
(switch user or substitute user) lets you switch user. su
basically starts another shell instance with the privileges of the intended user. By default it switches you to the root
user, if we want to switch specific user we need to pass user as follows:
$ su bob # switches to bob (requires bob's password)
su -
means environment variables will be reset to root and su
means environment variables as old user.
for example: root's home directory if you use su -
or old user home directory if you use su
.
sudo (super user do) is a command-line utility that allows users to run programs with the security privileges of another user, by default is superuser i.e root
. It uses a config file /etc/sudoers
which lists which users have rights to specific actions
sudo should be read as /ˈsuːduː/. syntax sudo command
i.e. switch user and do this command.
su
is equivalent tosudo -i
and simulates a login into the root account. Your working
directory will be/root
, and it will read root's.profile
etc.sudo -s
launches a shell as root, but doesn't change your working
directory.sudo bash
wherebash
is command to run withsudo
. This command runs
bash
as a super user.- Using
sudo
can be logged everything someone does. - Using
sudo
prevents a user from having to know the root password. - Using
sudo
we can limit the commands are allowed to run.
add a comment |
su
(switch user or substitute user) lets you switch user. su
basically starts another shell instance with the privileges of the intended user. By default it switches you to the root
user, if we want to switch specific user we need to pass user as follows:
$ su bob # switches to bob (requires bob's password)
su -
means environment variables will be reset to root and su
means environment variables as old user.
for example: root's home directory if you use su -
or old user home directory if you use su
.
sudo (super user do) is a command-line utility that allows users to run programs with the security privileges of another user, by default is superuser i.e root
. It uses a config file /etc/sudoers
which lists which users have rights to specific actions
sudo should be read as /ˈsuːduː/. syntax sudo command
i.e. switch user and do this command.
su
is equivalent tosudo -i
and simulates a login into the root account. Your working
directory will be/root
, and it will read root's.profile
etc.sudo -s
launches a shell as root, but doesn't change your working
directory.sudo bash
wherebash
is command to run withsudo
. This command runs
bash
as a super user.- Using
sudo
can be logged everything someone does. - Using
sudo
prevents a user from having to know the root password. - Using
sudo
we can limit the commands are allowed to run.
su
(switch user or substitute user) lets you switch user. su
basically starts another shell instance with the privileges of the intended user. By default it switches you to the root
user, if we want to switch specific user we need to pass user as follows:
$ su bob # switches to bob (requires bob's password)
su -
means environment variables will be reset to root and su
means environment variables as old user.
for example: root's home directory if you use su -
or old user home directory if you use su
.
sudo (super user do) is a command-line utility that allows users to run programs with the security privileges of another user, by default is superuser i.e root
. It uses a config file /etc/sudoers
which lists which users have rights to specific actions
sudo should be read as /ˈsuːduː/. syntax sudo command
i.e. switch user and do this command.
su
is equivalent tosudo -i
and simulates a login into the root account. Your working
directory will be/root
, and it will read root's.profile
etc.sudo -s
launches a shell as root, but doesn't change your working
directory.sudo bash
wherebash
is command to run withsudo
. This command runs
bash
as a super user.- Using
sudo
can be logged everything someone does. - Using
sudo
prevents a user from having to know the root password. - Using
sudo
we can limit the commands are allowed to run.
edited Aug 18 at 2:18
answered Sep 17 '16 at 9:33
Premraj
1,01011017
1,01011017
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f35338%2fsu-vs-sudo-s-vs-sudo-i-vs-sudo-bash%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
I prefer to use
sudo su -
This way you don't need the root password, and the-
makes sure the home directory is set right.– Jens Timmerman
Apr 26 '13 at 10:34
See also Which is the safest way to get root privileges: sudo, su or login?
– Gilles
Aug 21 '15 at 22:22