11-07-2005
In addition to avoiding accidents like reborg talked about, it is also a security issue. A virus, trojan, or hacker can insert nasty code with the same name as a common Unix command anywhere and hope root executes it by accident if "." at the start of root's path.
For example, if I break into your box as a normal non-root user, I could create a file named "cd" in some directory I have write access to. What if my script has one simple command:
rm -rf $1
Now when root tries to cd to anywhere from the directory I put my script in, it wipes out that directory instead. Alternately, you could have your script email vital files to the attacker, change data, or any other bad thing you can imagine. If you can trick root into running it for you, he's hosed.
It's basically the same thing as reborg said I guess. But you may have thought "I'd never name a script like that and cause a problem." My example above is why you still shouldn't have . in your path - you might not do something dumb yourself, but having . in the path makes it easier for the bad guys to get you.
10 More Discussions You Might Find Interesting
1. UNIX for Advanced & Expert Users
Hi,
When I try to run a script with ". "(dot space) in my home, it gives me error ".: Permission denied".
Any explanation for this behaviour?
Thanks in advance,
-Ashish (3 Replies)
Discussion started by: shriashishpatil
3 Replies
2. Shell Programming and Scripting
Hallo,
i need a Prompting read in my script:
read -p "Enter your command: " command
But i always get this Error:
-p: is not an identifier
When I run these in c-shell i get this error
/usr/bin/read: read: bad option(s)
How can I use a Prompt in the read command? (9 Replies)
Discussion started by: wiseguy
9 Replies
3. Shell Programming and Scripting
I had the idea come into my head that it would be good to have a single command that gave file type, file size, last modification date, and owner/group information, like what one would see in a GUI "Properties" dialog, but all in a terminal window. In my opinion, these statistics about a file... (5 Replies)
Discussion started by: SilversleevesX
5 Replies
4. Shell Programming and Scripting
Hi
I have a "set" command which ends with a "." (dot), for example:
set `grep "\<${pnum}\>" /tstmp/data.txt |sed 's/#//'` .
Can somebody help me to understand the purpose of this "set" and "." combination?
The problem is that this command does not produce the same result when run on AIX... (2 Replies)
Discussion started by: aoussenko
2 Replies
5. Shell Programming and Scripting
hello,
I am writting a regular expression that intend to match any tunnel or serial interface but it doesn't mtach any serial sub-interface.
For example, statement should match "Tunnel3" or "Serial0/1" but shouldn't match "Serial0\1.1" (doesn't include dot ".")
I tried the following but... (3 Replies)
Discussion started by: ahmed_zaher
3 Replies
6. Shell Programming and Scripting
Hi,
I have line in input file as below:
3G_CENTRAL;INDONESIA_(M)_TELKOMSEL;SPECIAL_WORLD_GRP_7_FA_2_TELKOMSEL
My expected output for line in the file must be :
"1-Radon1-cMOC_deg"|"LDIndex"|"3G_CENTRAL|INDONESIA_(M)_TELKOMSEL"|LAST|"SPECIAL_WORLD_GRP_7_FA_2_TELKOMSEL"
Can someone... (7 Replies)
Discussion started by: shis100
7 Replies
7. Shell Programming and Scripting
If I enter (simplified):
find . -printf "%p\n"
then all files in the output are prepended by a "." like
./local/share/test23.log
How can achieve that
a.) the leading "./" is omitted
and/or
b.) the full path to the current directory is inserted (enclosed by brackets and a blank)... (1 Reply)
Discussion started by: pstein
1 Replies
8. Shell Programming and Scripting
Hi,
I'm dealing with an issue and losing a lot of hours figuring out how i would solve this.
I have an input file which looks like this:
('BLABLA +200-GRS','Serviço ','TarifaçãoServiço','wap.bla.us.0000000121',2985,0,55,' de conversão em escada','Dia','Domingos')
('BLABLA +200-GRR','Serviço... (6 Replies)
Discussion started by: poliver
6 Replies
9. Shell Programming and Scripting
Hello.
Following recommendations for one of my threads, this is working perfectly :
#!/bin/bash
CNT=$( grep -c -e "some text 1" -e "some text 2" -e "some text 3" "/tmp/log_file.txt" )
Now I need a grep success for some thing like :
#!/bin/bash
CNT=$( grep -c -e "some text_1... (4 Replies)
Discussion started by: jcdole
4 Replies
10. Shell Programming and Scripting
These three finds worked as expected:
$ find . -iname "*.PDF"
$ find . -iname "*.PDF" \( ! -name "*_nobackup.*" \)
$ find . -path "*_nobackup*" -prune -iname "*.PDF"
They all returned the match:
./folder/file.pdf
:b:
This find returned no matches:
$ find . -path "*_nobackup*" -prune... (3 Replies)
Discussion started by: wolfv
3 Replies
chroot(2) System Calls Manual chroot(2)
NAME
chroot() - change root directory
SYNOPSIS
DESCRIPTION
causes the named directory to become the root directory, the starting point for path searches for path names beginning with path points to
a path name naming a directory. The user's working directory is unaffected by the system call.
The entry in the root directory is interpreted to mean the root directory itself. Thus, cannot be used to access files outside the subtree
rooted at the root directory.
Security Restrictions
The effective user ID of the process must be a user with the privilege to change the root directory.
See privileges(5) for more information about privileged access on systems that support fine-grained privileges.
RETURN VALUE
returns the following values:
Successful completion.
Failure.
is set to indicate the error.
ERRORS
fails and the root directory remains unchanged if one or more of the following is true:
Any component of the path name is not a directory.
The named directory does not exist or a component of the
path does not exist.
The effective user
ID is not a user who has the privilege.
path points outside the allocated address space of the process. The reliable detection of this error is implementation
dependent.
The length of the specified path name exceeds
bytes, or the length of a component of the path name exceeds bytes while is in effect.
Too many symbolic links were encountered in translating the path
name.
WARNINGS
Obsolescent Interfaces
is to be obsoleted at a future date.
SEE ALSO
chroot(1M), chdir(2), privileges(5).
STANDARDS CONFORMANCE
TO BE OBSOLETED chroot(2)