Mike Castle wrote:
> On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen <dotancohen@gmail.com> wrote:
>> Put the new bin BEFORE the old path.
>
> Huh? Why?
>
>
According to "Learning the BASH Shell" by Cameron Newham and Bill
Rosenblatt it is dangerous to have personal bin directory listed before
the public bin directories.
I have no idea what the policy is for quoting excerpts from a book so
I've chosen to leave it out. If it's ok, I'll be happy to give up the
couple of lines.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-13-2009, 06:08 PM
"Dotan Cohen"
stuff in ~/bin won't run
2009/1/13 Daryl Styrk <darylstyrk@gmail.com>:
> Mike Castle wrote:
>> On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen <dotancohen@gmail.com> wrote:
>>> Put the new bin BEFORE the old path.
>>
>> Huh? Why?
>
> According to "Learning the BASH Shell" by Cameron Newham and Bill
> Rosenblatt it is dangerous to have personal bin directory listed before
> the public bin directories.
>
> I have no idea what the policy is for quoting excerpts from a book so
> I've chosen to leave it out. If it's ok, I'll be happy to give up the
> couple of lines.
>
The first path with a matching name will be used. So if you have the
systemwide /usr/bin/firefox and your own personal ~/bin/firefox you
_must_ have your personal bin listed first in the path to get run.
Why is that dangerous? Because if your account is compromised then
critical system programs (ls, cd, and the like) can be easily replaced
with compromised versions. Putting your own bin at the end of the path
is meant to thwart this.
> I have no idea what the policy is for quoting excerpts from a book so
> I've chosen to leave it out. If it's ok, I'll be happy to give up the
> couple of lines.
>
Fair use: pretty much it you can type it out in a few lines it's fair game.
Daryl Styrk writes:
> I have no idea what the policy is for quoting excerpts from a book so 've
> chosen to leave it out.
In the US the "policy" is the bit of copyright law called "Fair Use". It
says you can quote excerpts without permission without infringing
copyright.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-13-2009, 06:18 PM
Steve Kemp
stuff in ~/bin won't run
On Tue Jan 13, 2009 at 21:08:02 +0200, Dotan Cohen wrote:
> Why is that dangerous? Because if your account is compromised then
> critical system programs (ls, cd, and the like) can be easily replaced
> with compromised versions. Putting your own bin at the end of the path
> is meant to thwart this.
If your account is compromised then why do you imagine your
settings will be untouched?
People typically put their ~/bin directory first, precisely
so that they can override system-wide commands.
As for why it didn't work - the OP seemed to have said:
PATH = ...
(ie. Spaces around the equals sign. This will not work.)
Steve
--
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-13-2009, 06:25 PM
"Dotan Cohen"
stuff in ~/bin won't run
2009/1/13 Steve Kemp <skx@debian.org>:
> On Tue Jan 13, 2009 at 21:08:02 +0200, Dotan Cohen wrote:
>
>> Why is that dangerous? Because if your account is compromised then
>> critical system programs (ls, cd, and the like) can be easily replaced
>> with compromised versions. Putting your own bin at the end of the path
>> is meant to thwart this.
>
> If your account is compromised then why do you imagine your
> settings will be untouched?
>
Exactly, this is the fallacy.
> People typically put their ~/bin directory first, precisely
> so that they can override system-wide commands.
>
Exactly.
> As for why it didn't work - the OP seemed to have said:
>
> PATH = ...
>
> (ie. Spaces around the equals sign. This will not work.)
>
I gave him an example of a valid .bash_profile file.
Dotan Cohen wrote:
> 2009/1/13 Daryl Styrk <darylstyrk@gmail.com>:
>> Mike Castle wrote:
>>> On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen <dotancohen@gmail.com> wrote:
>>>> Put the new bin BEFORE the old path.
>>> Huh? Why?
>> According to "Learning the BASH Shell" by Cameron Newham and Bill
>> Rosenblatt it is dangerous to have personal bin directory listed before
>> the public bin directories.
>>
>> I have no idea what the policy is for quoting excerpts from a book so
>> I've chosen to leave it out. If it's ok, I'll be happy to give up the
>> couple of lines.
>>
>
> The first path with a matching name will be used. So if you have the
> systemwide /usr/bin/firefox and your own personal ~/bin/firefox you
> _must_ have your personal bin listed first in the path to get run.
>
> Why is that dangerous? Because if your account is compromised then
> critical system programs (ls, cd, and the like) can be easily replaced
> with compromised versions. Putting your own bin at the end of the path
> is meant to thwart this.
>
>> I have no idea what the policy is for quoting excerpts from a book so
>> I've chosen to leave it out. If it's ok, I'll be happy to give up the
>> couple of lines.
>>
>
> Fair use: pretty much it you can type it out in a few lines it's fair game.
>
"This is unsafe because you are trusting that your own version of the
more command works properly. But it is also risky for a more important
reason: system security. If your PATH is set up in this way, you leave
open a "hole" that is well known to computer crackers and mischief
makers: they can install "Trojan horses" and do other things to steal
files or do damage."
There is a senerio that goes on to detail how a user with a suid script
in their personal bin directory before a public bin. Creating a Trojan
that looks for a common utility such as grep..
The example script..
"cp /bin/bash filenamechown root filenamechmod 4755 filename/bin/grep
"$@"rm ~/bin/grep"
"Sits back and waits for the user to run the suid shell script—which
calls the Trojan horse, which in turn creates the suid shell and then
self-destructs."
If you have the book I'm looking at chapter 10. 10.3.2 to be exact.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-13-2009, 06:38 PM
JoeHill
stuff in ~/bin won't run
Dotan Cohen wrote:
> 2009/1/13 Steve Kemp <skx@debian.org>:
> > On Tue Jan 13, 2009 at 21:08:02 +0200, Dotan Cohen wrote:
> >
> >> Why is that dangerous? Because if your account is compromised then
> >> critical system programs (ls, cd, and the like) can be easily replaced
> >> with compromised versions. Putting your own bin at the end of the path
> >> is meant to thwart this.
> >
> > If your account is compromised then why do you imagine your
> > settings will be untouched?
> >
>
> Exactly, this is the fallacy.
>
> > People typically put their ~/bin directory first, precisely
> > so that they can override system-wide commands.
> >
>
> Exactly.
Could you not just give your versions of the apps you want to run different
names? Would that not be safer? What I've done in the past is to add _mine to
end of the names, ie. 'todisc_mine'.
> > As for why it didn't work - the OP seemed to have said:
> >
> > PATH = ...
> >
> > (ie. Spaces around the equals sign. This will not work.)
> >
>
> I gave him an example of a valid .bash_profile file.
--
J
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-13-2009, 06:43 PM
Sven Joachim
stuff in ~/bin won't run
On 2009-01-13 20:28 +0100, Daryl Styrk wrote:
> "This is unsafe because you are trusting that your own version of the
> more command works properly. But it is also risky for a more important
> reason: system security. If your PATH is set up in this way, you leave
> open a "hole" that is well known to computer crackers and mischief
> makers: they can install "Trojan horses" and do other things to steal
> files or do damage."
The book in general is not so bad, but this statement, in fact the whole
paragraph, is just nonsense.
> There is a senerio that goes on to detail how a user with a suid script
> in their personal bin directory before a public bin. Creating a Trojan
> that looks for a common utility such as grep..
For one thing, the suid bit is ignored for scripts on Linux. And your
~/bin directory should never be writable by other people.
> The example script..
> "cp /bin/bash filenamechown root filenamechmod 4755 filename/bin/grep
> "$@"rm ~/bin/grep"
Will just not work, unless the user executing the script is root.
> "Sits back and waits for the user to run the suid shell script—which
> calls the Trojan horse, which in turn creates the suid shell and then
> self-destructs."
>
> If you have the book I'm looking at chapter 10. 10.3.2 to be exact.
Do you have the third edition? The second edition which I own does not
have sections inside the chapters numbered.
Sven
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-13-2009, 06:50 PM
"Dotan Cohen"
stuff in ~/bin won't run
2009/1/13 JoeHill <joehill@teksavvy.com>:
> Could you not just give your versions of the apps you want to run different
> names? Would that not be safer? What I've done in the past is to add _mine to
> end of the names, ie. 'todisc_mine'.
>
Depends on what you are doing. Here is a good example of appending
locale information to a command, and I _always_ want that:
> 2009/1/13 JoeHill <joehill@teksavvy.com>:
> >
> > I'm used to ~/bin being automatically picked up in my path, so therefore I
> > am absolutely clueless as to how to add it. Also, considering the potential
> > consequences to my system, I would rather not do it the wrong way
> >
> > This was what came up on a search, is this correct?
> >
> > export PATH =$PATH:/new/path/to/add
> >
>
> Yes, so for you it would be:
> export PATH =$PATH:/bin
The funny thing is, I already have this in my .bash_profile:
# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:"${PATH}"
fi
> Note that I personally prefer .bin to bin as then I do not have to see
> it in my file manager!
--
J
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
stuff in ~/bin won't run
