Bash: sudo -S <<< “mypassword” - interactive shell issue












0















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?










share|improve this question

























  • 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
















0















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?










share|improve this question

























  • 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














0












0








0








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 55 mins ago









Sergiy Kolodyazhnyy

73.2k9153317




73.2k9153317










asked 4 hours ago









LauraLaura

535




535













  • 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



















  • 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

















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










1 Answer
1






active

oldest

votes


















0














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 duplicate 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).






share|improve this answer

























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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 duplicate 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).






    share|improve this answer






























      0














      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 duplicate 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).






      share|improve this answer




























        0












        0








        0







        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 duplicate 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).






        share|improve this answer















        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 duplicate 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).







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 56 mins ago

























        answered 1 hour ago









        Sergiy KolodyazhnyySergiy Kolodyazhnyy

        73.2k9153317




        73.2k9153317






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            How did Captain America manage to do this?

            迪纳利

            南乌拉尔铁路局