I'm using python with setcap CAP_NET_RAW enabled. My python script imports a shared library which has $ORIGIN in its RPATH. Since my python is now a suid app, $ORIGIN is not evaluated and the library does not load correctly (this is due to a security leak found in glibc ).
Is there a way to tell the linker that my library path is secure and load the library anyway?
A few more notes:
I only need this feature in the development stage. I'm not looking for a production solution.
When working as root, everything works.
I do not want to work as root.
Thanks,
Dave
You can try one of these. Consider that <path-to-mylib> is the absolute pathname after solving the $ORIGIN rpath reference.
Re-run ldconfig after telling it where to find your library
$ echo "<path-to-mylib>" > /etc/ld.so.conf.d/my-new-library.conf
$ ldconfig -v
If running things as root is not an option, export LD_LIBRARY_PATH with the correct directory for every execution of the process
$ echo "export LD_LIBRARY_PATH=<path-to-mylib>" >> ~/.bashrc
$ export LD_LIBRARY_PATH=<path-to-mylib>
$ # then run your stuff...
Did you try sudo?
Instead of $ORIGIN, use fixed paths during development because they will work on setuid programs. Don't change your main build process, just use patchelf to set the rpath to what you need. You could make a shell script which does something like:
ln=`readelf -d |grep RPATH`
IFS=:
set -- $ln
newrpath=`echo $2 |sed 's/\$ORIGIN/\/devel\/myprog\/lib/'`
patchelf --set-rpath newrpath myprogram
Then your binary will no longer search $ORIGIN/../lib but /devel/myprog/lib/../lib
Related
first i used command : which gcc
If it shows location other than /usr/bin, then how to set the right path to compile the C program
It depends upon your $PATH. And that could be set to something starting with a directory containing some gcc command. Run echo $PATH to find out what is your current $PATH.
You could either type exactly /usr/bin/gcc, or add some alias to your interactive shell configuration (often ~/.bashrc which you might edit with great care), or change your PATH setting, or, assuming which gcc gives something like /home/zaid/bin/gcc (i.e. your $HOME/bin/gcc if $HOME/bin appears early in your $PATH), add a symbolic link ln -sv /usr/bin/gcc $HOME/bin/.
If you compile a program made of several translation units, you should use some build automation tool, probably GNU make. Try once make -p to understand the builtin rules known to your make and take advantage of these. Then, edit your Makefile, perhaps by adding near its beginning lines like
CC=/usr/bin/gcc
CFLAGS+= -Wall -g
The first line (with CC=) sets your C compiler in your Makefile. The second one (with CFLAGS+=) asks for all warnings (-Wall) & debug info (-g). Because you'll use the gdb debugger.
While the man for env on Linux seems to indicate that you can set new environment variables before executing a command. Unfortunately, when I set new variables in a file's shebang on Linux systems, the file never executes.
#!/usr/bin/env VAR1=foo bash
echo $VAR1
When I execute this file on a CentOS or Ubuntu machine, it just sits there.
$ ./shell-env.sh
<nothing happens>
What I find particularly bizarre is this works perfectly fine on OS X with BSD env.
$ ./shell-env.sh
foo
$
Is this just a difference between BSD env and Linux env? Why do the man pages for Linux seem to say it should work the same way as on BSD?
P.S. My use case here is to override the PATH variable, so I can try to find a ruby on the system but that's not on the PATH.
Thank you in advance!
There's a way to manipulate the environment before executing a Ruby script, without using a wrapper script of some kind, but it's not pretty:
#!/bin/bash
export FOO=bar
exec ruby -x "$0" "$#"
#!ruby
puts ENV['FOO']
This is usually reserved for esoteric situations where you need to manipulate e.g. PATH or LD_LIBRARY_PATH before executing the program, and it needs to be self-contained for some reason. It works for Perl and possibly others too!
I've incurred a worrisome issue with my bash shell. I was editing my bash_profile and accidentally exported an incomplete command (export PATH=/usr/local/bin). After I had reloaded my terminal, nearly all of my bash commands fail to work properly. When I try to run any one of them, the errors state: command not found.
How do I fix this? Is there an alternate way to open or find my bash_profile?
I would appreciate any immediate input I can get on this issue. Thank you in advance.
You can execute commands if you can give the directory name. Almost all the basic Unix commands are under the /bin or /usr/bin directory. For example, /bin/mv.
Fortunately, builtin commands are still recognizable.
Move your .bash_profile and .bashrc file out of the way for now, and see what the system default is.
You can manually edit your PATH on the command line to:
$ PATH="/bin:/usr/bin"
$ cd
$ mv .bash_profile .bash_profile.bak
$ mv .bashrc .bashrc.bak
$ mv .profile .profile.bak
$ mv .bash_login .bash_login.bak
NOTE: Some of these mv command may fail simply because that particular file may not exist.
which will give you access to most of the basic Unix commands. Or you can specify the commands with their full directory names:
$ PATH="/bin:/usr/bin"
$ cd
$ /bin/mv .bash_profile .bash_profile.bak
$ /bin/mv .bashrc .bashrc.bak
$ /bin/mv .profile .profile.bak
$ /bin/mv .bash_login .bash_login.bak
Now, log in again and see what your default $PATH is set to. This is set by the /etc/profile. You might find that's just fine, and remove setting PATH in your startup script.
The standard for PATH is something like this:
/usr/share/bin or /usr/local/bin - These contain non-standard Unix/Linux commands. For example, if you install Maven on your system, the mvn command will usually be located in one of these directories (maybe as a symbolic link). This directory is a place where commands not found in the /bin and /usr/bin directory are stored. This directory is first, so you can replace the version which came with your system with more recent versions. For example, I might have VIM 6.4 installed, but I want to use version 7.3 instead.
/bin:/usr/bin - The standard directories where 99% of the Unix commands live.
$HOME/bin - These are executables you wrote -- either scripts or binaries. This is at the end of the PATH list because it makes sure that you don't accidentally execute the wrong version of the command. Imagine if some joker wrote a shell script called cp that executed /bin/rm instead and placed it in your $HOME/bin directory.
Other directories you'll see may include /sbin/ and /usr/sbin which are administrator commands (ping and ifconfig are sometimes in one of these directories.) /opt/bin/X11 (or wherever the X11 binaries are stored). Sometimes other commands will futz around with your PATH, for example Perlbrew.
#fedorqui's comment provides a quick fix.
The OP could also have used the following to quickly get to a shell with default values for $PATH:
To create a bash shell with a pristine default environment:
without running profile/initialization scripts
without inheriting any environment variables from the current shell
run:
/usr/bin/env -i bash --norc
Note:
Due to use of env's -i option, many environment variables that are normally set will NOT be set in the resulting shell , such as USER, HOME and LANG.
Similarly, the $PATH value you'll get is presumably one hard-coded into bash itself, but it should provide access to at least the standard utilities.
--norc suppresses loading of ~/.bashrc, which normally happens by default for interactive non-login bash shells (bash also supports the --noprofile option to suppress loading of /etc/profile and ~/.bash_profile, but it doesn't apply here, since the shell created is a non-login shell).
If env is in the current shell's $PATH, env -i bash --norc will do.
env is in /usr/bin/ on at least Linux and on FreeBSD/OSX, probably also on other platforms.
I have an old version of a program sitting on my machine. This program recently had a version upgrade. The way I used to run my old program was by typing "runProgram". The path to the runscript of my program was specified in my PATH variable as
PATH = ....:/path/to/my/old/programs/bin
I want to run the new version of this same program alongside my old program and the way I was thinking of doing it was by modifying my PATH variable as follows:
PATH = ....:/path/to/my/old/programs/bin:/path/to/my/new/programs/bin
What I want to achieve is some way to alias these two paths so that when I type 'runVersion1', the previous version is executed and when I type 'runVersion2', the new version is executed?
Is there a way to achieve that?
Thanks
If the program itself runs other programs from the bin directory, then when you run a version 1 program, you want to ensure that the version 1 directory is on the PATH ahead of the version 2 directory, and vice versa when you run a version 2 program. That is something I deal with all the time, and I deal with it by ensuring that the PATH is set appropriately.
In my $HOME/bin, I would place two scripts:
RunVersion1
export PATH=/path/to/my/old/programs/bin:$PATH
# Set other environment variables as needed
exec runProgram "$#"
RunVersion2
export PATH=/path/to/my/new/programs/bin:$PATH
# Set other environment variables as needed
exec runProgram "$#"
This technique of placing shell scripts on my PATH ahead of other programs allows me to pick which programs I run.
Semi-Generic Version
Often, I'll use a single program to set the environment and then link it to the various program names that I want to handle. It then looks at $0 and runs that:
export PATH=/path/to/my/new/programs/bin:$PATH
# Set other environment variables as needed
exec $(basename $0 2) "$#"
If this script is linked to RunProgram2, the basename command lops off the 2 from the end of RunProgram2 and then executes RunProgram from the more recent directory.
I've used this general technique for accessing 32-bit and 64-bit versions of the software on a single machine, too. The programs I deal with tend to have more complex environments than just a setting of $PATH, so the scripts are bigger.
One of the main advantages of scripts in $HOME/bin over aliases and the like is that it doesn't much matter which shell I'm stuck with using; it works the same way. Plus I don't have so many places to look to find where the alias is defined (because it isn't defined).
I would put two alias definitions in your ~/.bashrc (depending what shell you are using).
alias runVersion1='/path/to/my/old/programs/bin/program'
alias runVersion2='/path/to/my/new/programs/bin/program'
After editing that file you need to relogin or simply execute
. ~/.bashrc
The way you suggest with $PATH won't do what you want. One way that might:
Given that usually, /usr/local/bin is in $PATH, and that that is the standard location for "local binaries", you do the following:
sudo ln -s /path/to/my/old/programs/bin/myprogram /usr/local/bin/runVersion1
sudo ln -s /path/to/my/new/programs/bin/myprogram /usr/local/bin/runVersion2
Alternatively, if you don't want it to be system-wide (i.e. instead, just for your user), you could:
ln -s /path/to/my/old/programs/bin/myprogram $HOME/bin/runVersion1
ln -s /path/to/my/new/programs/bin/myprogram $HOME/bin/runVersion2
(assuming $HOME/bin is in your $PATH)
Now this won't necessarily fix your problem - could use a little more information in the question, BUT it should help you get further with what you're trying to do.
how to go into the environment of "c". when using cygwin... please tell me the commands to go into the c environment....
If you want to cd to the C: drive then one way is:
$ cd /cygdrive/c
If you want to edit/compile/run/debug C programs, then it's:
$ emacs foo.c # edit
$ gcc -Wall foo.c -o foo # compile
$ ./foo # run
$ gdb ./foo # debug
Do you want to navigate to the C: drive when in the shell? If so, just do cd c:
Install cygwin from cygwin.org. Select development packages like gcc during the process. Open a cygwin shell and call gcc from the command line. Or whatever.
After reading the question, my first interpretation was that the question was about how to ensure that the C locale was set for the shell in Cygwin, rather than allowing the Windows locale to be inherited. Putting export LC_ALL=C or export LC_ALL=C.utf8 into your ~/.bashrc would force the C locale in all shell contexts. The command locale can be used to see your current locale before and after changing LC_ALL, which will help verify that the change is in effect. man bash (or your shell of choice) will provide more information on what is affected by the various locale-related environment variables.