Program can't load after setting the setuid bit on - c

Consider this scenario in which an executable A.bin uses libY.so and libZ.so. A.c, Y.c and Z.c are all written in C.
Z.c and Y.c are compiled into respective .so files.
This is the directory structure of the files
$home/bin/A.bin
$home/lib/libY.so
$home/lib/libZ.so
When I run A.bin as normal user, A.bin runs normally as expected.
Note: $LD_LIBRARY_PATH contains $home/lib
I changed some code in A.c adding some functionality which needs admin privileges(like binding to a port less than 1000).
I set the setuid bit for A.bin, libY.so and libZ.so to rwsrwsrws, and change the ownership of the files to root. When I try to run A.bin, I get the following error
ld.so.1: A.bin: fatal: libY.so: open failed: No such file or directory
Killed
When I just remove the setuid permission from all those files, then the binary runs except for the functionality fails where it needs root privileges.
How to overcome this problem ?
Edit: The OS is Solaris 5.10

As AProgrammer said, while executing setuid programs, $LD_LIBRARY_PATH is ignored. Hence the path has to be hardcoded in the executable itself using this flag while linking
gcc -R $home/lib
The -R flag builds runtime search path list into executable.

In some Unix variants, suid executables have some security features like ignoring LD_LIBRARY_PATH, checking ownership and access rights on the executable and used shared libraries,... I don't remember the case of Solaris, but you should probably check that.

Related

gcc won't compile to executable in shared folder

I have dual boot windows - ubuntu on my laptop. I wanted to have a shared partition for my documents so I created a fat partition with my files and mounted it on ubuntu.
The problem is the following:
I tried to create a simple "helloworld" program in C language (I named the file test.c). When the file is in ~/Documents I can compile and run it as expected. When I move test.c in shared directory, a.out file is created but it is not executable. If I chmod +x ./a.out, then the output is ./a.out: command not found.
Any idea?
The possible reason may be c language is not platform independent. So code written in one os won't be accessible from other os. As the folder is shared by two os this problem may have raised.

Program cannot load shared library GCC

First things first, here is the error message:
./Game: error while loading shared libraries: libEngine.so: cannot open shared object file: No such file or directory
There was no problems while compiling.
Library directories passed to GCC while compiling Game: -L../../bin -L.
Directory tree:
ENGINE
-bin
--Game (executable)
--libEngine.so
-Game
--src
---source code + Game makefile
-Engine
--src
---source code + shared library makefile
I can provide more info on demand.
Setting LD_LIBRARY_PATH is a possible, but usually not the best solution. In particular, dependence on environment produces programs which work for you, but not for your coworkers or your professor (because their environment is different).
Adding -rpath=/path/to/bin to the link line eliminates the need to muck with environment.
Even better: -rpath='$ORIGIN' lets you move the entire installation directory to a different place, and the program will still find its shared libraries in its own bin/ directory.

Substitute for LD_PRELOAD or LD_LIBRARY_PATH

I'm doing some C programming on a machine for which I don't have root access. I've compiled some shared libraries that I'm linking to, but because I cannot install the libraries in the typical location (/usr/local/lib) I have to explicitly specify the location of the libraries each time I compile and run. When compiling, this simply means adding the -L flag to the gcc command, but for program execution it's a lot more annoying. Either I must add the non-standard directory to LD_LIBRARY_PATH in each session, or I must add LD_PRELOAD=/path/to/libs to the beginning of the execute command.
Is there a better way to do this on a machine for which I don't have root access?
BTW, the machine is running Red Hat 4.1.
There are several solutions, from better to worse:
Use $ORIGIN, e.g. gcc main.o -L../lib -lfoo -Wl,-rpath='$ORIGIN'/../lib
Use target RPATH, e.g. gcc main.o -L../LIB -lfoo -Wl,-rpath=/home/user/lib
Set LD_LIBRARY_PATH from your .bashrc or .profile
Solution 1 allows you to install the binary anywhere, so long as you move the binary and the libraries together, e.g. my-app/bin/a.out and my-app/lib/{needed-shared-libs}.so. It also allows for multiple versions of the application and their set of shared libs.
Solution 2 works fine if you only need one set of shared libs, and never wish to move them around.
Solution 3 affects every application you run, and may cause some of them to bind to your shared libraries instead of the system ones. That may cause them to crash, fail with unresolved symbols, or cause you other pain. To exacerbate, the problem will only happen to you and nobody else, so you'll have hard time getting help for it.
You can add the environment variables to your .bashrc (or whatever file your shell sources when you log-in).
If you set the environment variable LD_RUN_PATH when you compile and link your program, then that search path will be baked in to the executable, and the dynamic linker will search it at runtime.
Using LD_LIBRARY_PATH or LD_PRELOAD is pretty much how to do this. To fix this, rename your program from myprog to myprog-exe, and create a shell script that looks like this called myprog:
#!/bin/sh
export LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH
`dirname $0`/myprog-exe
This way, when someone runs myprog, it will really run the shell script which then runs myprog.

Linking with -R and -rpath switches on Windows

I,m using gcc compiler(MinGW) on Windows XP.I created a .dll library libdir.dll than I tried to build a program that is using that library.
I don't want to put that .dll file into System or System32 folder nor to set path to it in PATH variable, what i want is to give that information to the program itself.
I know there is a -R and -rpath switches available so i was gonna link it with one of them.
First -rpath:
gcc -L/path/to/lib -Wl,-rpath,/path/to/lib main.o -ldir -o prog
Than -R:
gcc -L/path/to/lib -Wl,-R,/path/to/lib main.o -ldir -o prog
This links successfully into prog but when i start the program Windows prints message that it cannot find libdir.dll.
So my question is what went wrong, why path to libdir.dll is not known in runtime even when I'm using appropriate switches?
Let's say i have prog1 and prog2 each containing their own copy of libdir.dll and both of them start to run at the same time loading code in the library.What happens in memory is there a two copies loaded or linker figures out that there is a copy and uses that for both programs?
Second question is about how libraries are loaded(any OS).Does linkers always load entire library or just parts needed?For example if program references function foo() which is in the library, does linker maps into memory only that function or entire library first?
There are only two real alternatives: put the DLL in the same folder as the EXE or put it in the working directory for the EXE. The latter being not much of an option since you'd have to create a shortcut to make the default working directory different from the directory that contains the EXE.
Not putting the DLL in the same directory as the EXE only makes sense if you want to share the DLL with other applications. To avoid the inevitable DLL hell this causes, you'd need to store the DLL in the side-by-side cache. The tooling you need to create the manifest and embed it in the EXE and the installer you'd need to deploy the DLL to the target machine are probably hard to come by with your tool chain. It is very rarely done anyway.
Part of this question is a duplicate of this one: Is there a Windows/MSVC equivalent to the -rpath linker flag?
The summary of the answer is that there is no direct equivalent of RPATH on Windows.
Since you precluded placing your DLLs in the default library search path (which on Windows includes the system directories you listed and the directories in the PATH environment variable), you are left with these options:
using batch files
placing all the DLLs and executables in the same directory
making OS-level calls in your program for adding to the DLL search path

Using Cygwin to Compile a C program; Execution error

I'm enrolled in a masters computer science course. The course is using C and the instructor wants us to use Cygwin to compile programs if we are using windows.
I've downloaded and installed Cygwin and I've ensured that I've installed the GCC compiler.
But I don't know where to go from here. I need to compile a single source file that has a basic include.
#include <stdio.h>
Lets assume the file is on my desktop (it is not, but for the sake of argument). How do I navigate to the desktop from the bash shell? I assume once I've navigated to the correct location in bash, I simply execute:
gcc myProgram.c -o myProgram
Update: Following different instructions posted below, I was able to compile the program; I thank you for that. But when I execute the resulting binary I get the following. How can I compile or execute this program so I don't get the error? Again, thank you.
This application has failed to start because cygwin1.dll was not found. Re-installing the application may fix this problem.
when you start in cygwin, you are in your $HOME, like in unix generally, which maps to c:/cygwin/home/$YOURNAME by default. So you could put everything there.
You can also access the c: drive from cygwin through /cygdrive/c/ (e.g. /cygdrive/c/Documents anb Settings/yourname/Desktop).
Regarding your updated question about the missing cygwin1.dll.
From the Cygwin terminal check,
ls /usr/bin/cygwin1.dll
If it is not present (I doubt that), your installation is not properly done.
Then, check your path with,
echo $PATH
This will give : separated list of paths. It MUST contain /usr/bin. If you find that missing add it with,
export PATH=/usr/bin:$PATH
Finally,
I hope you are using Cygwin from the cygwin terminal (the little green+black icon installed with Cygwin), or MinTTY (if you installed that).
And, you have not moved the compiled EXE to a different machine which does not have Cygwin installed (if you do that, you will need to carry the cygwin1.dll to that machine -- keep it in the same folder as the compiled EXE).
Just to summarize, here are some commands that navigate to a directory and compile code using Cygwin and Windows Vista:
Start a Cygwin shell.
At the prompt, use cd to change to the appropriate directory:
$ cd /cygdrive/c/Users/nate/Desktop
Use ls to list the files in the directory:
$ ls
prog.c
Use the gcc command to compile a file in this directory:
$ gcc prog.c -o prog
If you don't see any errors, you should be able to run the resulting program:
$ ./prog
Update:
For the "Cygwin1.dll not found" error, I like Nik's answer. You might also check out this related post about cygwin1.dll not found, which suggests adding c:\cygwin\bin\ to your Windows PATH.
There are instructions on how to change the Windows PATH variable for Windows XP, and on Vista I think it's similar.
Go to Control Panel -> System
Select Advanced System Settings
Click on the Advanced tab
Click on Environment Variables
Under System Variables, find the Path entry and click Edit
Add c:\cygwin\bin to the list, making sure to separate it from any previous items with a semicolon
Look for (that is, cd to)
/cygdrive/c/
that will usually be your C:\
Also look at Using Cygwin, the Lifehacker introduction (June/2006) and, this biomed page at PhysioNet.
Regarding the cygwin1.dll not found error, a solution I have used for at least 8 years is to add the Cygwin bin directories to the end of my %PATH% in My Computer -> Properties -> Advanced -> Environment Variables. I add them to the end of the path so in my normal work, they are searched last, minimizing the possibility of conflicts (in fact, I have had no problems with conflicts in all this time).
When you invoke the Cygwin Bash Shell, those directories get prepended to the %PATH% so everything works as intended in that environment as well.
When not running in Cygwin shell, my %PATH% is:
Path=c:\opt\perl\bin; \
...
C:\opt\cygwin\bin; \
C:\opt\cygwin\usr\bin; \
C:\opt\cygwin\usr\local\bin;
This way, for example, ActiveState Perl's perl is found first when I am not in a Cygwin Shell, but the Cygwin perl is found when I am working in the Cygwin Shell.
If you are not comfortable with bash, you can continue to work in a standard windows command (i.e. DOS) shell.
For this to work you must add C:\cygwin\bin (or your local alternative) to the Windows PATH variable.
With this done, you may:
1) Open a command (DOS) shell
2) Change the directory to the location of your code (c:, then cd path\to\file)
3) gcc myProgram.c -o myProgram
As mentioned in nik's response, the "Using Cygwin" documentation is a great place to learn more.
If you just do gcc program.c -o program -mno-cygwin it will compile just fine and you won't need to add cygwin1.dll to your path and you can just go ahead and distribute your executable to a computer which doesn't have cygwin installed and it will still run. Hope this helps
Windows path C:\src under cygwin becomes /cygdrive/c/src
Compiling your C program using Cygwin
We will be using the gcc compiler on Cygwin to compile programs.
1) Launch Cygwin
2) Change to the directory you created for this class by typing
cd c:/windows/desktop
3) Compile the program by typing
gcc myProgram.c -o myProgram
the command gcc invokes the gcc compiler to compile your C program.
You might be better off editing a file inside of cygwin shell. Normally it has default user directory when you start it up. You can edit a file from the shell doing something like "vi somefile.c" or "emacs somefile.c". That's assuming vi or emacs are installed in cygwin.
If you want to file on your desktop, you'll have to go to a path similar (on XP) to "/cygwindrive/c/Documents\ and\ Settings/Frank/Desktop" (If memory serves correctly). Just cd to that path, and run your command on the file.
Cygwin is very cool! You can compile programs from other systems (Linux, for example), and they will work. I'm talking communications programs, or web servers, even.
Here is one trick. If you are looking at your file in the Windows File Explorer, you can type "cd " in your bash windows, then drag from explorer's address bar into the cygwin window, and the full path will be copied! This works in the Windows command shell as well, by the way.
Also: While "cd /cygdrive/c" is the formal path, it will also accept "cd c:" as a shortcut. You may need to do this before you drag in the rest of the path.
The stdio.h file should be found automatically, as it would be on a conventional system.
This file (cygwin1.dll) is cygwin dependency similar to qt dependency.you must copy this file and similar files that appear in such messages error, from "cygwin/bin" to folder of the your program .Also this is necessary to run in another computer that have NOT cygwin!

Resources