My lab sheet says that if the $PATH in root has a trailing ".", it is likely that an attacker can gain superuser access by forcing an admin to operate as root to execute some malicious program. I dont understand this at all! Can someone explain to me what the above sentence means? And how do I remove the "."?
echo $PATH
/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb:.
This is in Solaris 10 btw.
In your ~/.profile file or maybe in your ~/.bashrc file (By ~/ I mean your home directory)
export PATH=/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb
Now you have removed the trailing .
BTW: /usr/xpg4/bin has more modern versions of commands like awk - you may want to put it in your PATH variable before /usr/bin unless you were instructed to keep your PATH as is.
What the statement refers to is this:
Suppose the bad guys corrupted some executable file. One that lives in an application directory.
If you cd to that directory and then typed the name of the bad file it would run. And you might not know it happend. Maybe the file sends masses of of email all over the world. Or places a worm in some other executable file in your home directory. You get the idea.
Related
When I use command sudo vipw to edit my password file, It's always use vi as editor. I don't like this very much and want to change it to vim.
I already tried:
Add export EDITOR=/usr/local/bin/vim in /etc/profile.
But shell told me "export: Command not found". I thought the reason is export is built-in function only in bash. And I don't want to change my shell.
AddEDITOR=/usr/lcoal/bin/vim in default block of /etc/login.conf
Add setenv EDITOR vim in /root/.cshrc, /.cshrc, ~/.cshrc
All above didn't work at all.
I have google for hours but could not find anything help.
Your /etc/sudoers file doesn't keep your EDITOR environment variable.
I personally have an /etc/sudoers.d/local file, something like
# We don't need to worry about wheel users breaking in to get root access because they already have it.
Defaults:%wheel env_keep+="HOME EDITOR",!set_home,shell_noargs
I'm not sure why this isn't the default, since wheel users have already been given full access. But it's apparently prevailing wisdom to continue hassling them.
Note: If you're using an older /etc/sudoers file that doesn't support an /etc/sudoers.d directory, these lines can be dropped in there... or you could add #includedir /etc/sudoers.d as the last line of your /etc/sudoers file to enable an /etc/sudoers.d directory. Um, yes, the # is a required part of that line, because someone thought it was important for that directive to look like a comment.
Try adding this to the root user /root/.chsrc:
setenv EDITOR vim
or to set it globally to all users using shell tcsh/csh add it in /etc/csh.cshrc
From the man:
A login shell begins by executing commands from the system files /etc/csh.cshrc
and /etc/csh.login. It then executes commands from files in the user's home directory:
first ~/.tcshrc or, if ~/.tcshrc is not found, ~/.cshrc ...
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on startup.
Also verify vim is installed since is not by default, you could try:
pkg install vim-console
setting the EDITOR or VISUAL environment variable is the key.
if you don't want to go to the trouble of modifying config files (which is indeed the long term solution) then you could sudo su - to get to the root prompt and then you could export EDITOR=/usr/bin/vim before running vipw
There is an empty file called .selected_editor in $HOME (/root).
Remove it and the next call to vipw will ask you to select the editor.
I'm using a Centos 7 server. I'm entering the command echo $PATH and trying to figure out where it's getting the path that it's putting out. The path doesn't match what's in my .bash_profile, and there is no .bashrc file. How do I find out where my current $PATH is being sourced from?
The Default values for .bashrc and $PATH are stored in files /etc/bashrc and /etc/profile. These files are used by shell and kernel for setting default values for proper functioning of the server.
I would advise not to change any values here, as it might cause abnormal behavior in the server.
I have one python command file, i want to set it as a PATH in Solaris Sparc so that i can easily use my command from anywhere. For example the file name is abc.py and it contains abc --version to display version of file abc. So, after opening terminal i should only give command abc --version and it should display version of abc.
The architecture (SPARC) has nothing to do with the PATH which is more a shell thing but you do not tell what shell you are using.
Anyway, if you use a bourne style shell, i.e. not csh/tcsh, and you don't mind this to affect every user account on that host, you might add the wanted path to the PATH setting in the file /etc/profile.
When abc.py is located in your homedir, you can start it with ~/abc.py.
You need to call the file abc.py with abc.py, not abc (and have a shebang line which instructs the shell where it can find python).
When you want to start the file with ./abc, you can rename the file to abc (the shebang will tell it is python, not the .py), or introduce an alias:
alias abc="~/abc.py"
Using an alias can be an alternative for adding a shebang line:
alias abc="/usr/bin/python abc.py"
When you do not want to use an alias you can make a bin dir and put abc there.
I will add the shebang for you:
mkdir ~/bin
echo "#!/usr/bin/python" > ~/bin/abc
cat abc.py >> ~/bin/abc
chmod +x ~/bin/abc
mv abc.py bin/abc.py.old
Now change your login PATH with PATH=${PATH}:$HOME/bin in your .profile or .bashrc, and login again (or source the login script).
I am developing web applications using Ruby on Rails and Sublime Text 3 on OS X 10.8.4. I recently installed the package RubyTest. The tests only work when Sublime is launched using the command
subl
in terminal. Otherwise I get the error message:
/bin/sh: rspec: command not found
I think that's meant to be the case; that's implied in RubyTest's readme file on github.
However I'd like to retain the ability to launch from the dock. Is there a way I can do this?
Unfortunately, OSX applications do not pick up on your $PATH variable set in Terminal. To change the internal PATH settings in Mountain Lion (this method hasn't been tested with previous versions, although it should work), you'll need to edit /etc/launchd.conf:
Make sure you have admin privileges.
Open Terminal or your favorite substitute and see if there's anything in the file /etc/launchd.conf:
cat /etc/launchd.conf
If you get an error like
cat: /etc/launchd.con: No such file or directory
then continue with the next step. If the cat command does display some content, copy it to the clipboard.
Create a new text file with the following content, modified to fit your needs:
setenv PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/Users/YourUserName/bin:/path/to/gems/bin
If the cat command displayed some content in the previous step, paste it into the new file before the setenv PATH command. If it already contains a setenv PATH command, just modify it to add the directories you need, such as /path/to/gems/bin
Save the new file in your home directory (/Users/YourUserName) as launchd.conf.
Go back to Terminal and enter:
sudo mv ~/launchd.conf /etc
to use admin power to move the new file to /etc, replacing anything that was there before. Depending on your previous usage of the sudo command, you may get a short "be careful doing what you're doing" message, but either way you'll need to enter your password. /etc is not directly accessible through the Save dialog unless you're a real power user and know how to get around OSX's file system restrictions.
Reboot your computer
And you should be all set. If you're interested, launchd and launchctl use the csh/tcsh syntax, so you can't use the bash/zsh export PATH=/usr/local/bin:... format.
Trying to get a rails server running nicely.
downloaded ruby 1.8.7 using link from rails page.
did ./configure/make/install, installed it fine.
tried ruby -v , got nothing.
tried ./ruby -v from the folder and it worked.
I feel like i've gone from understanding something about unix, to completely lost. Clearly ruby is working as a 'daemon', but not running as it should. Any help would be MUCH appreciated. Losing too much hair through this process :(
J.
can you see where make install put the ruby executeable?
if you do, check if this dir is in your $PATH by
echo $PATH
In general, unix needs to know where to find the executable file to be able to run it. It uses $PATH to find this executable file.
So if you type "ruby" it will go look at you $PATH and then look in each of those directories for a file named "ruby". If it can't find it in any of those directories it should then also look in the current directory.
So, this whole process will fail if:
a) the directory that contains the executable ruby file is not in any of the directories in $PATH AND
b) the executable is not in the current directory
... one more alternative is that is is available in one of these directories... but is not actually marked as being executable by you. You can check this by making sure you're int e directory with the ruby file and typing "ls -l ./ruby"
That will list the ruby file along with all its permissions and who owns it.
It should be something like:
lrwxrwxrwx 1 root root 7 2010-02-14 10:45 ./ruby
Notice the rwx. If your ruby doesn't have x then you'll need to add executable permission using chmod eg: "chmod 755 ./ruby"
Also note the "root root" - that means it's owned by root - in general, this means that only root can run it. In this particular example it has eXecute permission for everyone so everybody can run it, but if you do not have execute permission set like this, then it means that if you are trying to run it as yourself, you won't have permission, and you should either add full permissions or try running it using: "sudo ruby"
However - by the sounds of it - the most likely problem is that you just don't have the ruby executable's directory in your $PATH. You will need to fix this even if you get it running right now - because, in future, you will need to run ruby from directories other than the current one.
You will need to google for instructions on adding things to your $PATH - because it differs depending on your version of linux and your current shell, but it's not very difficult.
Which shell are you running? If tcsh, you may need a "rehash". Otherwise, as leifg says, add the directory containing the ruby executable to your path.