Tag Info

New answers tagged

0

It is possible without being root but you should set SUID for your program. There is 2 way to do it which are exactly same anyway. chmod u+s [program] chmod 4755 [program] You may want to see SETUID Also If you handle this in C : You Should check setuid function And If you want to do it in bash : You should check setuid on shell scripts


2

To give a binary permission to run things as root, you need to set the "sticky bit" on the binary. Normally after compiling, you might see: # ls -l print -rwxr-xr-x 1 mark mark 111 24 Oct 17:32 print Setting the set-uid (sticky) bit can be done using and octal mode, or symbolically: # chown root print # chmod o-x print # chmod u+s print # ls -l print ...


0

chown root:root name_of_binary chmod 4755 name_of_binary


0

Usually, the capabilities are inherited to the children. As stated in the manpage : A child created via fork(2) inherits copies of its parent's capability sets. The issue with the scripts is they are not executables. Your calling program (usually the shell) has to check the first line for a shebang, then call the real interpreter (set in the shebang) ...


0

This answer might Help /usr/local The original idea behind '/usr/local' was to have a separate ('local') '/usr' directory on every machine besides '/usr', which might be just mounted read-only from somewhere else. It copies the structure of '/usr'. These days, '/usr/local' is widely regarded as a good place in which to keep self-compiled or third-party ...


3

That error (likely) means you are trying to run a 32-bit executable on a 64-bit system. I'll answer the specific issue here, but see the bottom of the answer for the better approach in general. You say have yum around, so this may help you: yum install lib/ld-linux.so.2 yum will try to find anything that provides that file and then install it. It should ...


0

There are multiple ways of installing a package in Linux/Unix. Installing using package managers like apt or rpm. Compiling the package from source code and installing them. These packages are compressed archives. Binary packages that come with an installation script or you might directly need to copy the binaries to appropriate location. These too come ...


0

You may try Scientific Linux 5.9, which has the advantage of being heavily tested among big academic communities of users (notably, CERN & Fermilab). If your application is of the scientific category, I suggest you check out this argument. Also, at least once in the past, CentOS did not want to collaborate with downloaded postgresql rpms, while SL worked ...


0

Another alternative you might consider is to collect those special executable scripts and programs into one directory and put that in the PATH statement. Thus you would not have to use the dreaded '.' (dot) in the PATH variable but still it would do what you wanted.


0

You should put the following line at the end of your .bashrc file: PATH=$PATH:. To do so you can type this command: echo "PATH=$PATH:." >> ~/.bashrc You should then start a new shell to have it work


0

Another way of doing this is to add an alias in your bashrc file: vim ~/.bashrc This is what my bashrc file looks like: # .bashrc alias coredb='psql -h 172.x.x.x -U jboss jbossdb' alias psql='psql -h 172.x.x.x -U rkah portal_db' alias opendb='psql -h 172.x.x.x -U rkah portal_db' # Source global definitions if [ -f /etc/bashrc ]; then . ...


2

You need add directory with your script to the PATH variable: export PATH=$PATH:/path/to/dir or you can even add current directory to the PATH: export PATH=$PATH:. The later has some security drawback though.


0

Another option is find /path -perm /u=x,g=x,o=x -type f It looks through /path, finds user, global and other executables that are regular files.


1

For Redhat based systems do this: ldd [file you want to run] | > needed-packages Check out needed-packages file, make sure there are no path names in the library file names. If so remove them, so "/bin/lib/libx.so.1" change to "libx.so.1" Find out what package contains the library yum -y provides [lib name] Or put this into a script or run from cmd ...


0

There is a builtin echo and a command echo. Use type -a echo to see all of them. Because type itself is a shell builtin it is able to know about other builtins. And which is only a usual command. Therefore it does not know which shell you are using and only tells you about commands on disk. Usually type is the correct command to tell you what happen if ...


7

For moving one program to other computer you have to move: 1) Executable file A simple way to finding commands path is type command. For example: type cal cal is /usr/bin/cal 2) Library dependencies You can find library dependencies with ldd command, But remember if you compiled a program from source the CPU Architecture of both server must be the ...


4

It sounds like opatch is a script. That is, it is a text file that starts with #! and lists its interpreter (maybe /bin/sh). Only compiled binaries (directly executable code) can be executed without read permission. For all scripts, no matter the interpreter (sh, python, etc...), the interpreter needs to be able to open the file, which mandates read ...


2

I think you're pointing to this from the man page: When the owner or group of an executable file are changed by an unprivileged user the S_ISUID and S_ISGID mode bits are cleared. So why are they cleared now. You see they are only cleared in case of an executable file. Because when one of the bits (SUID/SGID) is set, the unprivileged user can ...


1

I think you misread man 2 chown: you don't have to clear S_ISUID and S_ISGID, they will automatically be cleared when you use that function as an unprivileged user. If your program is running as root the behaviour (on Linux) depends on the kernel version. If you need the bits set, just reapply them (assuming the account that tries to set them has the ...


2

Google it. There isn't really a better way. It could be that some other software by the same name exists but no distribution has gotten around to packaging it yet. And even that isn't fully reliable: someone else could be doing the same thing right this minute and conclude that the name is available just as you do. You can check the package lists of major ...


0

Pipe the contents of chmod into an already executable file cp /usr/bin/executable_file ~/executable_file cat /usr/bin/chmod > ~/executable_file ~/executable_file +x file_to_be_executed.sh


1

Have you tried ./xcape ? You have to execute it this way, because the location is probably not defined in the $PATH variable.


0

I had a similar issue attempting a debootstrap for a Raspberry Pi as well. In fact, I found your posting while searching for a solution to my issue. I finally solved my issue and figured I'd add some notes here for others searching... I can confirm what was previously mentioned in this thread, the shell was crashing with a segfault in the debootstrap ...


17

You can use the Linux dynamic linker/loader directly to run ELF executables for which you have read, but not execute rights: $ /lib/ld-linux.so.* /home/user1/binary_program When an ELF executable is executed ordinarily, the dynamic linker which is stored in the .interp section of the program code is used. Reasons for invoking the dynamic linker directly ...


15

Since you have read permission: $ cp ~/binary_program my_binary $ chmod +x my_binary $ ./my_binary Of course this will not auto-magically grant you escalated privileges. You would still be executing that binary as a regular user.


0

As user johntex has noted in a comment to the answer by user Tobu, the simplest practical action in Bash is to rehash just your program: hash svnsync That's all.



Top 50 recent answers are included