Is adding ./bin a bad idea












6















I can't think of any reason why adding ./bin to my PATH environment would be a very bad idea.



I usually create bin folders in my projects that I am working in and I hate doing bin/command, it would be nice, to have command be picked up by bash as long as I am in the directory with a bin folder and that bin folder contains a command executable.



I need convincing :D










share|improve this question



























    6















    I can't think of any reason why adding ./bin to my PATH environment would be a very bad idea.



    I usually create bin folders in my projects that I am working in and I hate doing bin/command, it would be nice, to have command be picked up by bash as long as I am in the directory with a bin folder and that bin folder contains a command executable.



    I need convincing :D










    share|improve this question

























      6












      6








      6


      1






      I can't think of any reason why adding ./bin to my PATH environment would be a very bad idea.



      I usually create bin folders in my projects that I am working in and I hate doing bin/command, it would be nice, to have command be picked up by bash as long as I am in the directory with a bin folder and that bin folder contains a command executable.



      I need convincing :D










      share|improve this question














      I can't think of any reason why adding ./bin to my PATH environment would be a very bad idea.



      I usually create bin folders in my projects that I am working in and I hate doing bin/command, it would be nice, to have command be picked up by bash as long as I am in the directory with a bin folder and that bin folder contains a command executable.



      I need convincing :D







      bash binary






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Mar 10 '13 at 23:53









      whoamiwhoami

      1,58031923




      1,58031923






















          2 Answers
          2






          active

          oldest

          votes


















          4














          The $HOME/bin, . and ./bin are usually looked as a security risk.



          For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).



          For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.



          If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), it's because they do different things; what if you run the incorrect one?



          If you name your commands the same way (let's call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (particularly if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).



          It might look an innocent mistake, but they happen every day to many people! :)



          A good workaround (or better solution) is to use alias:



          alias proj1-cleanup=/srv/proj1/bin/cleanup


          and add on the script the correct cd to make sure it runs on the correct directory.



          This way, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.



          But hey, it's a personal choice; you are the one that knows what your local risks are and what the commands do.






          share|improve this answer


























          • I never thought of the sudo nano $file catch, awesome work higuita

            – whoami
            Mar 11 '13 at 0:34






          • 1





            Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

            – vonbrand
            Mar 11 '13 at 2:05








          • 4





            If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

            – Kotte
            Mar 11 '13 at 9:33



















          1














          On Ubuntu at least, this is part of the default user profile:



          # set PATH so it includes user's private bin if it exists
          if [ -d "$HOME/bin" ] ; then
          PATH="$HOME/bin:$PATH"
          fi


          I don't think it's a problem, but since it's user-writable and could transparently intercept commands, people can be nervous about it. Obviously this is a safer than ./bin, however.






          share|improve this answer























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


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f67520%2fis-adding-bin-a-bad-idea%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            The $HOME/bin, . and ./bin are usually looked as a security risk.



            For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).



            For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.



            If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), it's because they do different things; what if you run the incorrect one?



            If you name your commands the same way (let's call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (particularly if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).



            It might look an innocent mistake, but they happen every day to many people! :)



            A good workaround (or better solution) is to use alias:



            alias proj1-cleanup=/srv/proj1/bin/cleanup


            and add on the script the correct cd to make sure it runs on the correct directory.



            This way, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.



            But hey, it's a personal choice; you are the one that knows what your local risks are and what the commands do.






            share|improve this answer


























            • I never thought of the sudo nano $file catch, awesome work higuita

              – whoami
              Mar 11 '13 at 0:34






            • 1





              Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

              – vonbrand
              Mar 11 '13 at 2:05








            • 4





              If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

              – Kotte
              Mar 11 '13 at 9:33
















            4














            The $HOME/bin, . and ./bin are usually looked as a security risk.



            For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).



            For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.



            If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), it's because they do different things; what if you run the incorrect one?



            If you name your commands the same way (let's call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (particularly if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).



            It might look an innocent mistake, but they happen every day to many people! :)



            A good workaround (or better solution) is to use alias:



            alias proj1-cleanup=/srv/proj1/bin/cleanup


            and add on the script the correct cd to make sure it runs on the correct directory.



            This way, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.



            But hey, it's a personal choice; you are the one that knows what your local risks are and what the commands do.






            share|improve this answer


























            • I never thought of the sudo nano $file catch, awesome work higuita

              – whoami
              Mar 11 '13 at 0:34






            • 1





              Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

              – vonbrand
              Mar 11 '13 at 2:05








            • 4





              If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

              – Kotte
              Mar 11 '13 at 9:33














            4












            4








            4







            The $HOME/bin, . and ./bin are usually looked as a security risk.



            For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).



            For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.



            If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), it's because they do different things; what if you run the incorrect one?



            If you name your commands the same way (let's call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (particularly if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).



            It might look an innocent mistake, but they happen every day to many people! :)



            A good workaround (or better solution) is to use alias:



            alias proj1-cleanup=/srv/proj1/bin/cleanup


            and add on the script the correct cd to make sure it runs on the correct directory.



            This way, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.



            But hey, it's a personal choice; you are the one that knows what your local risks are and what the commands do.






            share|improve this answer















            The $HOME/bin, . and ./bin are usually looked as a security risk.



            For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).



            For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.



            If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), it's because they do different things; what if you run the incorrect one?



            If you name your commands the same way (let's call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (particularly if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).



            It might look an innocent mistake, but they happen every day to many people! :)



            A good workaround (or better solution) is to use alias:



            alias proj1-cleanup=/srv/proj1/bin/cleanup


            and add on the script the correct cd to make sure it runs on the correct directory.



            This way, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.



            But hey, it's a personal choice; you are the one that knows what your local risks are and what the commands do.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 52 mins ago









            Jeff Schaller

            41.5k1056132




            41.5k1056132










            answered Mar 11 '13 at 0:20









            higuitahiguita

            56549




            56549













            • I never thought of the sudo nano $file catch, awesome work higuita

              – whoami
              Mar 11 '13 at 0:34






            • 1





              Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

              – vonbrand
              Mar 11 '13 at 2:05








            • 4





              If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

              – Kotte
              Mar 11 '13 at 9:33



















            • I never thought of the sudo nano $file catch, awesome work higuita

              – whoami
              Mar 11 '13 at 0:34






            • 1





              Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

              – vonbrand
              Mar 11 '13 at 2:05








            • 4





              If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

              – Kotte
              Mar 11 '13 at 9:33

















            I never thought of the sudo nano $file catch, awesome work higuita

            – whoami
            Mar 11 '13 at 0:34





            I never thought of the sudo nano $file catch, awesome work higuita

            – whoami
            Mar 11 '13 at 0:34




            1




            1





            Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

            – vonbrand
            Mar 11 '13 at 2:05







            Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody.

            – vonbrand
            Mar 11 '13 at 2:05






            4




            4





            If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

            – Kotte
            Mar 11 '13 at 9:33





            If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk.

            – Kotte
            Mar 11 '13 at 9:33













            1














            On Ubuntu at least, this is part of the default user profile:



            # set PATH so it includes user's private bin if it exists
            if [ -d "$HOME/bin" ] ; then
            PATH="$HOME/bin:$PATH"
            fi


            I don't think it's a problem, but since it's user-writable and could transparently intercept commands, people can be nervous about it. Obviously this is a safer than ./bin, however.






            share|improve this answer




























              1














              On Ubuntu at least, this is part of the default user profile:



              # set PATH so it includes user's private bin if it exists
              if [ -d "$HOME/bin" ] ; then
              PATH="$HOME/bin:$PATH"
              fi


              I don't think it's a problem, but since it's user-writable and could transparently intercept commands, people can be nervous about it. Obviously this is a safer than ./bin, however.






              share|improve this answer


























                1












                1








                1







                On Ubuntu at least, this is part of the default user profile:



                # set PATH so it includes user's private bin if it exists
                if [ -d "$HOME/bin" ] ; then
                PATH="$HOME/bin:$PATH"
                fi


                I don't think it's a problem, but since it's user-writable and could transparently intercept commands, people can be nervous about it. Obviously this is a safer than ./bin, however.






                share|improve this answer













                On Ubuntu at least, this is part of the default user profile:



                # set PATH so it includes user's private bin if it exists
                if [ -d "$HOME/bin" ] ; then
                PATH="$HOME/bin:$PATH"
                fi


                I don't think it's a problem, but since it's user-writable and could transparently intercept commands, people can be nervous about it. Obviously this is a safer than ./bin, however.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 11 '13 at 0:21









                teppicteppic

                3,07711212




                3,07711212






























                    draft saved

                    draft discarded




















































                    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.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f67520%2fis-adding-bin-a-bad-idea%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

                    CARDNET

                    Boot-repair Failure: Unable to locate package grub-common:i386

                    濃尾地震