About " . ":
If you are a ordinary user or you can afford adding . in your $PATH (and understand its possible consequences...) at the condition its at the end of your PATH variable ( for security reason already mentionned ), if you were a developper you would I imagine create a bin directory in your $HOME and add that to your PATH variable instead, avoiding like that the risk of being spoofed...
About /usr/local/bin: Trust what the mods above already mentionned, since /usr/local/bin is set in PATH by default on most systems, it is not a good idea at all to let people other than root add new programs..., I for instance dont even trust the content.. and so remove /usr/local/bin from my PATH, and if I need a program that is there I check before its content.. You can always use aliases to your executable with fancy long absolute paths...
I saw a hole production fail for 5 weeks because someone not listening to what I said add . at the beginning of PATH in /etc/profile...
The side effects can be disastrous...
Last edited by vbe; 11-30-2012 at 10:25 AM..
Reason: typos
Ok, I kinda get that it might be about having executables in permissions protected directories, but if all you need to do is use the absolute pathname, it doesn't seem like much security.
You're missing the point. If you just type 'mycommand' and hit enter, you won't run something that's been maliciously dumped in a local directory by accident.
You can still do so with ./ but it will be hard to claim you did so by accident.
I think people are misunderstanding my question, or I haven't been clear enough. (Or possibly I've misunderstood your answers?) Please forgive my ignorance, I was only wondering why, when you are in the same directory as a file, (not only executables), to access it, you only need its name.
But to execute a file, you must add dot-slash.
In other words, why doesn't simply typing the name and hitting <ENTER> work?
Is it perhaps that using the pathname just indicates to the system that execution is your intention? Or that it forces you to do something extra, so you know you are executing something? Yes, that makes sense.
As a side note, I do understand what all of you have been telling me - that executables belong in protected directories, and all the very good reasons for that. I also understand why you encourage me to follow canonical unix protocols - someday I may working on something other than my own Macbook - maybe even a shell account accessed from my own Macbook at home. One should develop good habits.
---------- Post updated at 11:04 AM ---------- Previous update was at 10:54 AM ----------
Quote:
Originally Posted by Corona688
You're missing the point. If you just type 'mycommand' and hit enter, you won't run something that's been maliciously dumped in a local directory by accident.
You can still do so with ./ but it will be hard to claim you did so by accident.
Yes, this is what I was wondering about - the reason it's done this way, is simply that it forces you to realize what you are doing?
About " . ":
If you are a ordinary user or you can afford adding . in your $PATH (and understand its possible consequences...) at the condition its at the end of your PATH variable ( for security reason already mentionned ), if you were a developper you would I imagine create a bin directory in your $HOME and add that to your PATH variable instead, avoiding like that the risk of being spoofed...
Adding a relative directory into your PATH can have problems beyond the obvious.
Many shells cache a list of available commands they find in PATH. Put a relative directory in there, and they may not always find all available commands because they don't know the cache needs to be regenerated every time you cd. Some may even crash if you put a relative directory in PATH.
Yes, this is what I was wondering about - the reason it's done this way, is simply that it forces you to realize what you are doing?
That's a reason, but not the reason. The entire system uses PATH, not just you. This restriction gets rid of many unpredictable, unintended consequences.
The number of problems this could cause are potentially unlimited. It's not one specific problem, but a whole class of them. Imagine running commandname from your crontab, carelessly creating another file named commandname in your home directory to document what you've done, and seeing your cron log fill up with 'permission denied' for no reason you can explain -- because cron's trying to run your text document instead of /bin/commandname.
Having defined places where commands belong solves quite a lot.
P.S. It's not really the same issue as creating a new file. When you think about it, creating files is actually a lot more strict. It creates files in the current directory and only the current directory unless you force anything else. You wouldn't want 'nano bash' to open /bin/bash, after all. So running files, and creating files, are entirely separate things.
Last edited by Corona688; 11-30-2012 at 12:30 PM..
So running files, and creating files, are entirely separate things. UNIX likes to keep things separate like that. It can keep data and executables as far apart as different partitions for safety so you, out-of-control programs, malicious network worms, random disk corruption, and other nasties do as little damage as possible when they happen.
About " . ":
If you are a ordinary user or you can afford adding . in your $PATH (and understand its possible consequences...) at the condition its at the end of your PATH variable ( for security reason already mentionned ), if you were a developper you would I imagine create a bin directory in your $HOME and add that to your PATH variable instead, avoiding like that the risk of being spoofed...
About /usr/local/bin: Trust what the mods above already mentionned, since /usr/local/bin is set in PATH by default on most systems, it is not a good idea at all to let people other than root add new programs..., I for instance dont even trust the content.. and so remove /usr/local/bin from my PATH, and if I need a program that is there I check before its content.. You can always use aliases to your executable with fancy long absolute paths...
I saw a hole production fail for 5 weeks because someone not listening to what I said add . at the beginning of PATH in /etc/profile...
The side effects can be disastrous...
My situation is a little different. I'm just learning about unix and shell scripting at home on my Mac. Since the scripts I'm writing are useless except to learn how they work, I will never add them to my PATH. It's also rare that anyone else uses my computer. So it's convenient to write them in a sub-directory of my home directory, where I can execute them immediately after writing them, just to see that they work, and immediately go back to edit them. It's no problem to prepend dot-slash, and no need to alter my current PATH. I didn't see this as a problem, but because I'm a newb, things are not always obvious to me, and I wonder why some things are the way they are.
Add explicit route to 10.128.255.41/32 , gateway: 10.128.201.254
if not working, please try gateway through management port: 10.128.55.254
Just want to double confirm if this would be the correct command
#route add -net 10.128.255.41/32 10.128.201.254
And if didnt work
#route add... (1 Reply)
I have executed the below perl script for copying the file from one server to another server using scp.
#!/usr/bin/perl -w
use Net::SCP::Expect;
use strict;
$server= "x.x.x.x";
my $source = "/mypath/mypath";
my $destination = "/home/";
print "Login...Starting scp...";
$user="admin";... (1 Reply)
I want to run applet on AIX 6 machine.
I already have setup $DISPLAY variable for putty session by selecting X11 option.
I got below error for any X related commands (xclock, X, applet viewer )
X connection to localhost:10.0 broken (explicit kill or server shutdown). Please can anyone... (0 Replies)
I'm running IPF on solaris 10
bash-3.00# ipf -V #display ipf version
ipf: IP Filter: v4.1.9 (592)
Kernel: IP Filter: v4.1.9
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 1
Feature mask: 0x107
with the following rules
bash-3.00# ipfstat -o -i... (0 Replies)
Hi
Could someone help me?
I'm not sure how to find the full pathname of a directory.
I just want to be able to specify a directory.
e.g
directory1/directory2/directory3/directory4/directory5
I want to be able to put in "directory5"
and then i want a return of the full address.
... (3 Replies)
Hi All,
We use tomcat web server and it will get terminated with below error:
connection to localhost:10.0 host broken (explicit kill or server shutdown)
Please let me know how to fix this error. (5 Replies)
With C Shell you can get the root, head, tail and extension of a pathname by using pathname variable modifiers.
Example Script:
#! /bin/csh
set pathvar=/home/WSJ091305.txt
echo $pathvar:r
echo $pathvar:h
echo $pathvar:t
echo $pathvar:e
The result of executing this script is:
... (7 Replies)
How can I get the results of a find back without the pathname
for example if i do
find ../../ -name \*.sql
i dont want to see
directory/directory/filename.sql
I only want to see filename.sql (3 Replies)