[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange/incorrect behavior of a fake executable file
From: |
Greg Wooledge |
Subject: |
Re: Strange/incorrect behavior of a fake executable file |
Date: |
Wed, 14 Mar 2018 08:43:45 -0400 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Tue, Mar 13, 2018 at 10:29:22PM -0600, Eduardo Bustamante wrote:
> On Tue, Mar 13, 2018 at 7:24 PM, Vladimir Likic <v.likic@gmail.com> wrote:
> > Repeat-By:
> >
> > $ echo junk > junk
> > $ chmod +x junk
> > $./junk
> > --> this completely destroys my system
Only if you have "." in your $PATH (or a function named junk that
recurses into itself, etc.).
You've written a program that recursively calls itself by name, but
only if that name can be found in a directory that is in your $PATH.
This is ONE of the reasons why you should never put "." into your $PATH.
Which in turn is why you need to write "./junk" to run a program in the
current directory instead of just "junk".
You have included "." in your $PATH (or you are doing this in ~/bin or
/usr/local/bin or something). Now "junk" works to invoke the program,
and you get the infinite recursion which brings your system to its knees.
> Uh, what do you mean by that? And how is this a bash bug?
>
> A few points:
>
> 1) You do not provide a hash-bang (i.e. #!/bin/bash), which means that
> /bin/sh will be used (
No, that's incorrect. When bash tells the operating system to run
this program, the operating system will return ENOEXEC (Exec format
error). Bash (and every other shell) will catch this and spawn a
child copy of itself to try to interpret the program as a script.
So, in the absence of a shebang, the file is interpreted as a command
script by whatever shell the user happens to be using at the time.
> 2) You are using Debian apparently. /bin/sh in Debian is dash, not bash
> 3) What's the value of PATH? (I'm guessing you have an empty entry or
> '.' in there, and therefore, the script calls itself recursively).
> It's not good practice to have the current working directory in your
> PATH, so, fix that.
The smart money is definitely on ". or '' in $PATH". The only other
option I see is that the user was working inside a directory that is
in $PATH (~/bin or /usr/local/bin or whatever). Too bad he didn't
use a PS1 that shows $PWD in his example.