Bash: sudo -S <<< “mypassword” - interactive shell issue
I'm trying to use sudo
with -S
to issue the password via command line.
$ sudo -S <<< "mypassword" command
This works, but it doesn't allow for interactive commands. Like nano
for example:
$ sudo -S <<< "mypassword" nano /tmp/foo
It automatically closes the nano session. Same with apt-get
:
$ sudo -S <<< "mypassword" apt-get install foo
It closes before I can press "y" to install foo. I know I can pass -y
with apt but overall, this is frustrating.
Also tried stuff like this, but it still fails to engage with interactive session:
$ sudo -S <<< "mypassword" -H -u root bash -c "apt-get install foo"
Is it possible to use -S
with sudo without cancelling all interactive shells?
command-line bash sudo redirect
add a comment |
I'm trying to use sudo
with -S
to issue the password via command line.
$ sudo -S <<< "mypassword" command
This works, but it doesn't allow for interactive commands. Like nano
for example:
$ sudo -S <<< "mypassword" nano /tmp/foo
It automatically closes the nano session. Same with apt-get
:
$ sudo -S <<< "mypassword" apt-get install foo
It closes before I can press "y" to install foo. I know I can pass -y
with apt but overall, this is frustrating.
Also tried stuff like this, but it still fails to engage with interactive session:
$ sudo -S <<< "mypassword" -H -u root bash -c "apt-get install foo"
Is it possible to use -S
with sudo without cancelling all interactive shells?
command-line bash sudo redirect
Since with-S
you're tellingsudo
to read from stdin, effectively blocking the child command's access to stdin. Why do you want to use-S
and not aNOPASSWD
rule?
– Olorin
4 hours ago
Just to point out the obvious, passing passwords in such way is bad idea for security reasons. Passwords can be intercepted and they get stored into shell's history as well. See security.stackexchange.com/a/184158/121824
– Sergiy Kolodyazhnyy
1 hour ago
add a comment |
I'm trying to use sudo
with -S
to issue the password via command line.
$ sudo -S <<< "mypassword" command
This works, but it doesn't allow for interactive commands. Like nano
for example:
$ sudo -S <<< "mypassword" nano /tmp/foo
It automatically closes the nano session. Same with apt-get
:
$ sudo -S <<< "mypassword" apt-get install foo
It closes before I can press "y" to install foo. I know I can pass -y
with apt but overall, this is frustrating.
Also tried stuff like this, but it still fails to engage with interactive session:
$ sudo -S <<< "mypassword" -H -u root bash -c "apt-get install foo"
Is it possible to use -S
with sudo without cancelling all interactive shells?
command-line bash sudo redirect
I'm trying to use sudo
with -S
to issue the password via command line.
$ sudo -S <<< "mypassword" command
This works, but it doesn't allow for interactive commands. Like nano
for example:
$ sudo -S <<< "mypassword" nano /tmp/foo
It automatically closes the nano session. Same with apt-get
:
$ sudo -S <<< "mypassword" apt-get install foo
It closes before I can press "y" to install foo. I know I can pass -y
with apt but overall, this is frustrating.
Also tried stuff like this, but it still fails to engage with interactive session:
$ sudo -S <<< "mypassword" -H -u root bash -c "apt-get install foo"
Is it possible to use -S
with sudo without cancelling all interactive shells?
command-line bash sudo redirect
command-line bash sudo redirect
edited 55 mins ago
Sergiy Kolodyazhnyy
73.2k9153317
73.2k9153317
asked 4 hours ago
LauraLaura
535
535
Since with-S
you're tellingsudo
to read from stdin, effectively blocking the child command's access to stdin. Why do you want to use-S
and not aNOPASSWD
rule?
– Olorin
4 hours ago
Just to point out the obvious, passing passwords in such way is bad idea for security reasons. Passwords can be intercepted and they get stored into shell's history as well. See security.stackexchange.com/a/184158/121824
– Sergiy Kolodyazhnyy
1 hour ago
add a comment |
Since with-S
you're tellingsudo
to read from stdin, effectively blocking the child command's access to stdin. Why do you want to use-S
and not aNOPASSWD
rule?
– Olorin
4 hours ago
Just to point out the obvious, passing passwords in such way is bad idea for security reasons. Passwords can be intercepted and they get stored into shell's history as well. See security.stackexchange.com/a/184158/121824
– Sergiy Kolodyazhnyy
1 hour ago
Since with
-S
you're telling sudo
to read from stdin, effectively blocking the child command's access to stdin. Why do you want to use -S
and not a NOPASSWD
rule?– Olorin
4 hours ago
Since with
-S
you're telling sudo
to read from stdin, effectively blocking the child command's access to stdin. Why do you want to use -S
and not a NOPASSWD
rule?– Olorin
4 hours ago
Just to point out the obvious, passing passwords in such way is bad idea for security reasons. Passwords can be intercepted and they get stored into shell's history as well. See security.stackexchange.com/a/184158/121824
– Sergiy Kolodyazhnyy
1 hour ago
Just to point out the obvious, passing passwords in such way is bad idea for security reasons. Passwords can be intercepted and they get stored into shell's history as well. See security.stackexchange.com/a/184158/121824
– Sergiy Kolodyazhnyy
1 hour ago
add a comment |
1 Answer
1
active
oldest
votes
File descriptors are inherited
What you're using is <<<
aka here-string, and that type of redirection is implemented via temporary files that are immediately unlinked (aka deleted). Knowing also that processes inherit file descriptors (and stdin among them) from parent to child, when sudo -S
is performed, it reads its input from the temporary file that your original shell has passed to it (the one that reads sudo -S
command). You can see that in action:
$ sudo -S bash -c 'ls -l /proc/self/fd/0' <<< "mypasswd"
lr-x------ 1 root root 64 Feb 26 13:12 /proc/self/fd/0 -> '/tmp/sh-thd.cUOOXU (deleted)'
Thus, nano
reports Too many errors from stdin
error in such case. What can be done is to manually re-wire where stdin
is coming from.
$ sudo -S bash -c 'exec < /dev/tty; nano /tmp/foobar' <<< "mypasswd"
$ sudo -S bash -c 'nano /tmp/foobar < /dev/tty' <<< "mypasswd"
Either of the two commands will lauch nano
properly and other commands as well. /dev/tty
is the special file representing current terminal device, and it is effectively the same thing as stdin
of "normal" interactive shell (and of course I am oversimplifying that statement).
Another variation on the theme is $ sudo -S bash -c 'nano /tmp/foobar 0>&1' <<<"mypasswd"
. stdout
effectively points to the same terminal device (unless you've explicitly provided a redirection to have stdout point somewhere else). Thus, if we make stdin
point to be the dup
licate of stdout
, it's effectively the same solution as above. (And if you're wondering why I highlighted dup
part, that's because dup2()
syscall is the one responsible for all the juggling of file descriptors under the hood)
Caution
However, note that I don't encourage using sudo -S
in interactive shell, since passwords will remain in shell's history
$ sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
^C
$ history 2
2016 sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
2017 history 2
sudo -S
is more appropriate for use with other processes, where sudo -S
would expect input via pipeline, ideally from zenity --password
or dialog --passwordbox "foobar text" 200 200
(see extra1 and extra2 about dialog).
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2faskubuntu.com%2fquestions%2f1121283%2fbash-sudo-s-mypassword-interactive-shell-issue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
File descriptors are inherited
What you're using is <<<
aka here-string, and that type of redirection is implemented via temporary files that are immediately unlinked (aka deleted). Knowing also that processes inherit file descriptors (and stdin among them) from parent to child, when sudo -S
is performed, it reads its input from the temporary file that your original shell has passed to it (the one that reads sudo -S
command). You can see that in action:
$ sudo -S bash -c 'ls -l /proc/self/fd/0' <<< "mypasswd"
lr-x------ 1 root root 64 Feb 26 13:12 /proc/self/fd/0 -> '/tmp/sh-thd.cUOOXU (deleted)'
Thus, nano
reports Too many errors from stdin
error in such case. What can be done is to manually re-wire where stdin
is coming from.
$ sudo -S bash -c 'exec < /dev/tty; nano /tmp/foobar' <<< "mypasswd"
$ sudo -S bash -c 'nano /tmp/foobar < /dev/tty' <<< "mypasswd"
Either of the two commands will lauch nano
properly and other commands as well. /dev/tty
is the special file representing current terminal device, and it is effectively the same thing as stdin
of "normal" interactive shell (and of course I am oversimplifying that statement).
Another variation on the theme is $ sudo -S bash -c 'nano /tmp/foobar 0>&1' <<<"mypasswd"
. stdout
effectively points to the same terminal device (unless you've explicitly provided a redirection to have stdout point somewhere else). Thus, if we make stdin
point to be the dup
licate of stdout
, it's effectively the same solution as above. (And if you're wondering why I highlighted dup
part, that's because dup2()
syscall is the one responsible for all the juggling of file descriptors under the hood)
Caution
However, note that I don't encourage using sudo -S
in interactive shell, since passwords will remain in shell's history
$ sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
^C
$ history 2
2016 sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
2017 history 2
sudo -S
is more appropriate for use with other processes, where sudo -S
would expect input via pipeline, ideally from zenity --password
or dialog --passwordbox "foobar text" 200 200
(see extra1 and extra2 about dialog).
add a comment |
File descriptors are inherited
What you're using is <<<
aka here-string, and that type of redirection is implemented via temporary files that are immediately unlinked (aka deleted). Knowing also that processes inherit file descriptors (and stdin among them) from parent to child, when sudo -S
is performed, it reads its input from the temporary file that your original shell has passed to it (the one that reads sudo -S
command). You can see that in action:
$ sudo -S bash -c 'ls -l /proc/self/fd/0' <<< "mypasswd"
lr-x------ 1 root root 64 Feb 26 13:12 /proc/self/fd/0 -> '/tmp/sh-thd.cUOOXU (deleted)'
Thus, nano
reports Too many errors from stdin
error in such case. What can be done is to manually re-wire where stdin
is coming from.
$ sudo -S bash -c 'exec < /dev/tty; nano /tmp/foobar' <<< "mypasswd"
$ sudo -S bash -c 'nano /tmp/foobar < /dev/tty' <<< "mypasswd"
Either of the two commands will lauch nano
properly and other commands as well. /dev/tty
is the special file representing current terminal device, and it is effectively the same thing as stdin
of "normal" interactive shell (and of course I am oversimplifying that statement).
Another variation on the theme is $ sudo -S bash -c 'nano /tmp/foobar 0>&1' <<<"mypasswd"
. stdout
effectively points to the same terminal device (unless you've explicitly provided a redirection to have stdout point somewhere else). Thus, if we make stdin
point to be the dup
licate of stdout
, it's effectively the same solution as above. (And if you're wondering why I highlighted dup
part, that's because dup2()
syscall is the one responsible for all the juggling of file descriptors under the hood)
Caution
However, note that I don't encourage using sudo -S
in interactive shell, since passwords will remain in shell's history
$ sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
^C
$ history 2
2016 sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
2017 history 2
sudo -S
is more appropriate for use with other processes, where sudo -S
would expect input via pipeline, ideally from zenity --password
or dialog --passwordbox "foobar text" 200 200
(see extra1 and extra2 about dialog).
add a comment |
File descriptors are inherited
What you're using is <<<
aka here-string, and that type of redirection is implemented via temporary files that are immediately unlinked (aka deleted). Knowing also that processes inherit file descriptors (and stdin among them) from parent to child, when sudo -S
is performed, it reads its input from the temporary file that your original shell has passed to it (the one that reads sudo -S
command). You can see that in action:
$ sudo -S bash -c 'ls -l /proc/self/fd/0' <<< "mypasswd"
lr-x------ 1 root root 64 Feb 26 13:12 /proc/self/fd/0 -> '/tmp/sh-thd.cUOOXU (deleted)'
Thus, nano
reports Too many errors from stdin
error in such case. What can be done is to manually re-wire where stdin
is coming from.
$ sudo -S bash -c 'exec < /dev/tty; nano /tmp/foobar' <<< "mypasswd"
$ sudo -S bash -c 'nano /tmp/foobar < /dev/tty' <<< "mypasswd"
Either of the two commands will lauch nano
properly and other commands as well. /dev/tty
is the special file representing current terminal device, and it is effectively the same thing as stdin
of "normal" interactive shell (and of course I am oversimplifying that statement).
Another variation on the theme is $ sudo -S bash -c 'nano /tmp/foobar 0>&1' <<<"mypasswd"
. stdout
effectively points to the same terminal device (unless you've explicitly provided a redirection to have stdout point somewhere else). Thus, if we make stdin
point to be the dup
licate of stdout
, it's effectively the same solution as above. (And if you're wondering why I highlighted dup
part, that's because dup2()
syscall is the one responsible for all the juggling of file descriptors under the hood)
Caution
However, note that I don't encourage using sudo -S
in interactive shell, since passwords will remain in shell's history
$ sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
^C
$ history 2
2016 sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
2017 history 2
sudo -S
is more appropriate for use with other processes, where sudo -S
would expect input via pipeline, ideally from zenity --password
or dialog --passwordbox "foobar text" 200 200
(see extra1 and extra2 about dialog).
File descriptors are inherited
What you're using is <<<
aka here-string, and that type of redirection is implemented via temporary files that are immediately unlinked (aka deleted). Knowing also that processes inherit file descriptors (and stdin among them) from parent to child, when sudo -S
is performed, it reads its input from the temporary file that your original shell has passed to it (the one that reads sudo -S
command). You can see that in action:
$ sudo -S bash -c 'ls -l /proc/self/fd/0' <<< "mypasswd"
lr-x------ 1 root root 64 Feb 26 13:12 /proc/self/fd/0 -> '/tmp/sh-thd.cUOOXU (deleted)'
Thus, nano
reports Too many errors from stdin
error in such case. What can be done is to manually re-wire where stdin
is coming from.
$ sudo -S bash -c 'exec < /dev/tty; nano /tmp/foobar' <<< "mypasswd"
$ sudo -S bash -c 'nano /tmp/foobar < /dev/tty' <<< "mypasswd"
Either of the two commands will lauch nano
properly and other commands as well. /dev/tty
is the special file representing current terminal device, and it is effectively the same thing as stdin
of "normal" interactive shell (and of course I am oversimplifying that statement).
Another variation on the theme is $ sudo -S bash -c 'nano /tmp/foobar 0>&1' <<<"mypasswd"
. stdout
effectively points to the same terminal device (unless you've explicitly provided a redirection to have stdout point somewhere else). Thus, if we make stdin
point to be the dup
licate of stdout
, it's effectively the same solution as above. (And if you're wondering why I highlighted dup
part, that's because dup2()
syscall is the one responsible for all the juggling of file descriptors under the hood)
Caution
However, note that I don't encourage using sudo -S
in interactive shell, since passwords will remain in shell's history
$ sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
^C
$ history 2
2016 sudo -S bash -c 'sleep 3m' <<< "ohnomypassword"
2017 history 2
sudo -S
is more appropriate for use with other processes, where sudo -S
would expect input via pipeline, ideally from zenity --password
or dialog --passwordbox "foobar text" 200 200
(see extra1 and extra2 about dialog).
edited 56 mins ago
answered 1 hour ago
Sergiy KolodyazhnyySergiy Kolodyazhnyy
73.2k9153317
73.2k9153317
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f1121283%2fbash-sudo-s-mypassword-interactive-shell-issue%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
Since with
-S
you're tellingsudo
to read from stdin, effectively blocking the child command's access to stdin. Why do you want to use-S
and not aNOPASSWD
rule?– Olorin
4 hours ago
Just to point out the obvious, passing passwords in such way is bad idea for security reasons. Passwords can be intercepted and they get stored into shell's history as well. See security.stackexchange.com/a/184158/121824
– Sergiy Kolodyazhnyy
1 hour ago