running git 'post-receive' hook with setuid fails - c++

I have a git repository that needs to run a post-receive hook as sudo. The binary that I compiled to test this looks like:
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
int main() {
int ret;
ret = setuid(geteuid());
if(!ret) {
fprintf(stderr, "error setting uid %d \n", ret);
}
system("[...command only sudo can access...]");
return 0;
}
The geteuid() retrieves the owner id of post-receive, then tries to setuid. When running this with any user(including the super user) it runs the script correctly as root. However, when triggered by the git hook the systems fail to set the uid. I have tried running chmod u+s post-receive I also tried some other configurations, but I am running out of ideas. Any reason why it would work in all cases except when git triggers it?
btw, platform Ubuntu Server 9.04(2.6.28-15), git1.6.0.4, gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)


The file system where the git repo is stored may be mounted with the nosuid option
If you are pushing over ssh the suid capability may be disabled for commands invoked with ssh (no CAP_SETUID)
In any case, what you are trying to do is very inadvisable.


Run your program as a daemon.
Wait for input on a socket/named pipe/msgq.
In the hook, send a message to your daemon with whatever info it needs to perform the operation.
If needed, send a message back to the hook with status.
This will likely be easier to manage and secure properly.


try running your program from the command prompt


Try writing a bootstrap script. ie
#/usr/bin/sh
./your_program
Then make make the script the hook.

Related

AppImage and CAP_SYS_BOOT using setcap: ./app.AppImage differs in [pe]

I am trying to grant reboot capability to my appimage using setcap. Using following command on a simple application (all it does is to reboot the machine) works, however it does not work with my actual app's appimage.
Both applications essentially do the same thing for rebooting:
sync();
if(reboot(RB_AUTOBOOT) == -1) {
// handle errno
}
(In case you want to try the code, include <unistd.h> and <sys/reboot.h>)
Output with minimal test app:
sudo setcap -v cap_sys_boot+ep ./main
./main: OK
Output with appimage:
sudo setcap -v cap_sys_boot+ep ./app.AppImage
./app.AppImage differs in [pe]
Any idea what can I do?

CLion remote debugging will not kill remote process

I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.

This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.

my system V init script don't return

This is script content, located in /etc/init.d/myserviced:
#!/lib/init/init-d-script
DAEMON="/usr/local/bin/myprogram.py"
NAME="myserviced"
DESC="The description of my service"
When I start the service (either by calling it directly or by calling sudo service myserviced start), I can see program myprogram.py run, but it did not return to command prompt.
I guess there must be something that I misunderstood, so what is it?
The system is Debian, running on a Raspberry Pi.

After more works, I finally solved this issue. There are 2 major reasons:
init-d-script actually calls start-stop-daemon, who don't work well with scripts specified via --exec option. When killing scripts, you should only specify --name option. However, as init-d-script always fill --exec option, it cannot be used with script daemons. I have to write the sysv script by myself.
start-stop-daemon won't magically daemonize the thing you provide. So the executable provided to start-stop-daemon should be daemonized itself, but not a regular program.

Libssh2: prevent background task from being killed

I am writing a program that logs into another system via SSH using the libssh2 library. Once logged in, I execute a command using:
libssh2_channel_exec(sshchannel, command)
The command executes okay. However, once I close the channel the process running is killed. In my case, the command (executing a binary executable) will run for a long period of time and my program cannot wait for it to terminate. I've tried issuing the following commands all to the same result (the process is still killed upon closing the channel):
/path/myprog
nohup /path/myprog
nohup /path/myprog &
/path/myprog &; disown
Further, I've observed this behavior for both libssh and libssh2. Is there some option or command I am missing?
Thanks in advance.

you can use the unix at command:
echo "cmd" | at now

Child_info_fork error running code on cygwin [duplicate]

I recently reinstalled Cygwin on my computer in order to get access to several command line elements that I was missing. I have never had previous difficulty with Cygwin, but after this reinstallation, an error message continues to appear after (almost) each command entered. For instance:
-bash-4.1$ wc m1.txt
3 [main] bash 2216 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x38D000)
-bash: fork: retry: Resource temporarily unavailable
2013930 4027950 74968256 m1.txt
Generally, the command still runs (as seen above), but not always. Occasionally, the 'error' message occurs several times in a row (the initial number "3" will then change to a "4" or "2", notably if I start a second Cygwin window.
Also, as soon as I start up Cygwin, I get the following message before the prompt:
3 [main] bash 6140 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x36D000)
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash-4.1$
At the moment, I am debating whether to uninstall/reinstall Cygwin again or just live with the error messages, but I was curious if there might be an issue that I am unaware of.

(assuming Cygwin is installed at C:\Cygwin):
Open Task Manager and close any processes that look to be Cygwin related.
Open C:\Cygwin\bin in Windows Explorer
Verify that dash.exe, ash.exe, rebase.exe, and rebaseall exist in this folder
If any of them are missing, re-run Cygwin setup and select the dash, ash, and rebase packages
right-click your C:\Cygwin folder, uncheck Read-only (if its checked), and press OK.
When an error about not being able to switch some files comes up, select "Ignore All". Wait for this process to complete.
Browse to C:\Cygwin\bin in Windows Explorer
Right click dash.exe and click "Run as Administrator". A command Prompt should appear with nothing but a $
Type /usr/bin/rebaseall -v, hit enter, and wait for the process to complete.
If you get errors about Cygwin processes running, try Step 1 again. If that still doesn't work, Restart your computer into safe mode and try these steps again.
A commenter noted that, depending on your settings, you may have to type cd /usr/bin && ./rebaseall -v instead.
Try opening Cygwin again.
This process worked for me. I hope it works for you guys too.
Source: http://cygwin.wikia.com/wiki/Rebaseall

I would like to add the following to the above answers, as it is what I had to do after reinstalling Cygwin:
Navigate to the "/usr/bin" directory (usually, C:\cygwin\bin) and right click, Run as Administrator the file: dash.exe
Then, at the $ prompt type the following, hitting enter after each line:
cd /usr/bin/
/usr/bin/peflags * -d 1
/usr/bin/rebaseall -v
What it does is, it marks the dll's as "rebase-able," and then rebases them. You have to have peflags.exe in addition to the above files (in previous answers). You may have to restart windows after doing this and you will definitely need to make sure that there are no processes nor services belonging to cygwin running. (Use task manager, kill any related processes, and then under the services tab look for any service starting with CYG and stop it.)
After doing this, I was able to get cygwin to run without any errors about dll's being loaded to the wrong addresses aka fork errors, etc.
I hope that this helps others, as it was a pain to find.
SOURCE: http://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
and the rebase README file.

To add on to other answers here, we ran into the same issue but could not run the rebase command from the ash or dash shell. However, when launching the command from the Windows cmd shell, the following worked.
cmd /c "C:\cygwin64\bin\ash.exe /usr/rebaseall -v"
-v is to get verbose output

I found another information here :
http://cygwin.com/ml/cygwin/2014-02/msg00531.html
You have to delete the database at
/etc/rebase.db* and do in a "ash" windows :
peflags * -d 1
rebaseall
It works for me on 2 servers.

I solved this problem by restarting my computer. Probably installed a driver update and kept using sleep instead of shutting down.

Experienced the same issue when loading Cygwin with cygiconv-2.dll forking and not loading successfully in the Cygwin terminal, but after turning off my AntiVirus (it was specifically Ad-aware), the issue resolved, and Cygwin worked properly.

In case you are using babun's Cygwin, after rebaseall, try launching Cygwin by executing .babun\cygwin\cygwin.bat in a Windows command prompt or Windows explorer.
This works for me (while launching babun's default console - mintty results in fork error).

I had the error on win10 and i was trying to rebase to c: before install.
then i saw that the installer was installing it instead to c:/Users/myuser
so i was coping all files from c:/Users/myuser to c:.badun
and then restart plus open badun.bat
not shure if this was wise its now duplicated XD... but then it worked again.

Rebaseing didn't help in my case. In addition to what other people suggested, I noticed that reducing the length of PATH environment variable fixed the issue for me (and for other people as well as can be seen from this answer).

This issue is intermittent in nature & I found this issue when there is network is too slow to connect to remote machine on AWS.... I have Shell script that runs through Gitbash shell & it connects to AWS EC2 instance with ssh..... Most of the time, it ran correctly but 2 out 100 times it get into this issue bash: fork: retry: Resource temporarily unavailable .... Killing the MSYS2 terminal from task manager helps to overcome with this issue....
Negative side is you need to run the scripts from the beginning...

I had the same issue on Windows 10 and the mobaxterm app (which uses cygwin) and I tried all of answers listed here however for me, the solution was to simply delete the "CryptoPro CSP" application.

I started facing this problem after upgrading to windows 10. As of now I do not see that any of the above method working.
What I am noticing is that if you start cygwin with admin right (right click and say "run as admin") then it works fine.
Or you open cmd as administrator and then launch cygwin from there, then also it runs fine.

Just reinstall cygwin and select TCL and activate EXPECT