Is adding ./bin a bad idea
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
add a comment |
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
add a comment |
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
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
bash binary
asked Mar 10 '13 at 23:53
whoamiwhoami
1,58031923
1,58031923
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
I never thought of thesudo 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 likesl
forls
). 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 thensudo
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
add a comment |
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.
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%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
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.
I never thought of thesudo 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 likesl
forls
). 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 thensudo
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
add a comment |
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.
I never thought of thesudo 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 likesl
forls
). 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 thensudo
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
add a comment |
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.
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.
edited 52 mins ago
Jeff Schaller
41.5k1056132
41.5k1056132
answered Mar 11 '13 at 0:20
higuitahiguita
56549
56549
I never thought of thesudo 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 likesl
forls
). 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 thensudo
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
add a comment |
I never thought of thesudo 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 likesl
forls
). 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 thensudo
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 11 '13 at 0:21
teppicteppic
3,07711212
3,07711212
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.
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%2f67520%2fis-adding-bin-a-bad-idea%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