On 1/8/06, Shriramana Sharma wrote:

Sunday, 08 January 2006 11:09 samaye, Tom Peters alekhiit:

...

Where is it? Your current directory is not checked for executables in most shells, unlike that toy o/s MS-DOS. If there isn't a PATH to it, you will definitely have to specify ./filename

Thanks, all, for your interest. Apparently my previous post to the list was not delivered to the list because Simon Roberts's reply had a reply-to header to his id.

I have since been able to successfully run many programs using ./filename, but I do wonder why the current directory is not checked. What is wrong with that behaviour? And why should the DOS shell be derided for providing this facility?

This is due to security reasons. If the current directory is searched before others and you're currently in /tmp, a publicly writable directory, an attacker could place a malicious binary with named ls in /tmp. It would be executed instead of /bin/ls thus enabling attackers to run arbitrary commands. Imagine this happens when you're logged in as root. One could argue that placing the current directory as the last element in $PATH would be safe. If you're still in /tmp and invoke ls the $PATH variable is searched and /bin/ls is executed before ./ls if there is one. This is OK unless you invoke malicious binaries by accident (e.g. typing 'ud' instead of 'du') if the attacker has anticipated typical typing errors. If you want to be sure, do NOT place the current directory in you $PATH variable. \Steve -- Steve Graegert Software Consultant {C/C++ && Java && .NET} Office: +49 9131 7123988 Mobile: +49 1520 9289212

On 1/8/06, Mike McMullin wrote:

On Sun, 2006-01-08 at 13:14 +0530, Shriramana Sharma wrote:

...

Sunday, 08 January 2006 11:09 samaye, Tom Peters alekhiit:

...

Where is it? Your current directory is not checked for executables in most shells, unlike that toy o/s MS-DOS. If there isn't a PATH to it, you will definitely have to specify ./filename

Thanks, all, for your interest. Apparently my previous post to the list was not delivered to the list because Simon Roberts's reply had a reply-to header to his id.

I have since been able to successfully run many programs using ./filename, but I do wonder why the current directory is not checked. What is wrong with that behaviour? And why should the DOS shell be derided for providing this facility?

PWD may or may-not be in the path of the user. *nix checks the path first, DOS checks the path and the current directory. (I do mean checks, as DOS is still being used today, I've run 4 CNC machines that boot DOS, 2 MS-DOS and 2 DR-DOS).

I did a man exec and it seems to be a bash script executor, IIRC you had compiled the program in the original question, what impact could exec have in this situation?

When calling "exec ./myapp" the process image of the shell is replaced with the process image of myapp which is loaded from disk. When myapp returns the shell process is not available anymore, since it has been replaced with myapp. You will usually not use exec with interactive shells. \Steve -- Steve Graegert Software Consultant {C/C++ && Java && .NET} Office: +49 9131 7123988 Mobile: +49 1520 9289212

I have since been able to successfully run many programs using ./filename, but I do wonder why the current directory is not checked. What is wrong with that behaviour? And why should the DOS shell be derided for providing this facility? I'm just reiterating what has been said. The way things work is that if you do not provide a path, then the system searched each directory in your PATH variable. If the

On Sun, 8 Jan 2006 13:14:30 +0530 Shriramana Sharma wrote: directory with this program is not in your PATH variable, the system will not find it. The reason that the current directory is not included in the PATH variable by default is security. You can add it if you want. it is a standard practice in Linux and mode Unix systems not to include . in the path. The reason (I think this might also have been answered) is that if someone is able to put a trojan in some directory, you happen to be in that directory and the trojan has the same name of a commonly executed program (ls for instance) you can damage your system. Example: write a script and call it ls: #!/bin/bash rm -rf ~/ This will remove your entire home directory. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9