Good morning, I started a gdb debug session several hours ago. Is possible to use gdb to attach to a process already being debugged by gdb?
I tried to attach as root but I get the following error message:
[root#localhost lirh5g_deb]# gdb ./MatchUpAccurate.exe 12327
ptrace: Operation not permitted.
/home/frank/DQT/MatchUpTest/lirh5g_deb/12327: No such file or directory.
We are using Centos Linux Version 5.5. Thank you.
Unfortunately, not directly. Your only option, if you didn't use screen/tmux, is to search for a tty hijacker (it's possible to "steal" tty's - this is an ugly solution though) and grab the tty which has your existing gdb session
Related
So I follow the commands on the website.
I open one windows and I used the command: sudo make qemu-gdb. And it asked me to use another terminal to start gdb.
When I used the gdb provided by the Linux system. It shows this error message:
.gdbinit:2: Error in sourced command file:
Undefined item: "riscv:rv64".
What should I do to fix the issue?
You need to use riscv64-unknown-elf-gdb instead of gdb. It would be installed in your system when you install riscv-gnu-toolchain specified in xv6 site.
use /usr/bin/gdb-multiarch instead
riscv64-unknown-elf-gdb didn't come with the riscv-gnu-toolchain for me.
Using gdb-multiarch in ubuntu 18 works for me.
Your gdb version should be 8.3 and later
Replace all gdb with riscv64-unknown-elf-gdb when you are following the textbook and you should be good to go.
You can also run
riscv64-unknown-elf-gdb --version
to check the availability of this command. If something is not right, see this page to re-install the toolchain. (Remember to make clean before re-making to clean the temporary files.)
I have installed pam_script.so into my /lib/security/ folder and created a simple curses application at /etc/security/onsessionopen which executes whenever I attempt to login.
The script is executed, this much I know, but the terminal is not altered to show the curses application and instead it just logs out.
How can I force the ncurses application to show?
The answer is to force your own TTY and run the terminal application in there.
For more simple echoing, find the /dev/pts file descriptor that the current shell is using and direct all commands there.
pam_script.so is immensely useful.
Here's my working curses application with PAM setup which executes after 4 wrong attempts:
https://bitbucket.org/tetris11/custom-pam-curses-warning/
Running Ubuntu 14.04, and I have a script that is being run automatically when I boot the machine. For the life of me, I can't remember how or where I did this.
I already checked:
upstart (which doesn't seem to be available here, anyway)
/etc/rc.local
crontab (with #reboot)
/etc/init
/etc/init.d
.config/autostart (doesn't exist btw)
It's a script of my own, so it's not some kind of malicious virus or malware or anything. I just can't remember how I did this, and would like to know.
It has a distinct name, e.g. like ~/MyScriptXYZ.sh so I could search for that, IF I know how or where..?? (I'm a novice linux user)
A few other places you can look:
crontab -e as your own user and as root (local user crontab)
/etc/profile.d/ or /etc/profile
~/.profile
~/.bashrc
The last ditch attempt you can do is to cd / && grep -R "MyScriptXYZ" as root - this will take a while but will search all files on your computer for that reference :)
So I stumbled across this question and I managed to solve it for myself:
I was using Ubuntu (chroot) through the Linux Deploy Android app and I also couldn't find it. So to make the answer complete: Use pstree to locate and trace what is currently running and see where it's originating from.
Following Basile Starynkevitch's advice I managed to solve it by going to:
/home/[user]/.config/lxsession/LXDE/autostart and find it the code I added a while ago.
i am trying to emulate cavium octeon's mips64 linux kernel on Qemu.I am currently having some issues with use mode init code and want to debug init.i am starting the Qemu using -s -S option in the command line and running the gdb using command
ddd --debugger /OCTEON-SDK/tools/bin/mips64-octeon-linux-gnu-gdb /OCTEON-SDK/linux/kernel_2.6/linux/vmlinux
and then attaching the gdb with command
target remote localhost:1234
The gdb is currently showing only the instructions running in kernel space.
What i want to ask is there any method by which i can debug the usermode init and libraries instructions step by step as in case of kernel space?
For example if printf is issued from init then i want to see that which instructions are being executed in the libraries and how the control is returned to kernel ?
I have managed to step debug BusyBox's /sbin/init using the procedure described at: Is it possible to use gdb and qemu to debug linux user space programs and kernel space simultaneously?
The only additional things you have to keep in mind are:
/sbin/init is just a symlink to busybox, so you must use /bin/busybox as the object file
the "main" function for /sbin/init is actually init_main, following BusyBox' convention of calling the main for each pseudo-executable as <exec>_main
It is a bit flaky, but mostly just works.
I am debugging a program that makes use of libnetfilter_queue. The documentation states that a userspace queue-handling application needs the CAP_NET_ADMIN capability to function. I have done this using the setcap utility as follows:
$ sudo setcap cap_net_raw,cap_net_admin=eip ./a.out
I have verified that the capabilities are applied correctly as a) the program works and b) getcap returns the following output:
$ getcap ./a.out
./a.out = cap_net_admin,cap_net_raw+eip
However, when I attempt to debug this program using gdb (e.g. $ gdb ./a.out) from the command line, it fails on account of not having the correct permissions set. The debugging functionality of gdb works perfectly otherwise and debugs as per normal.
I have even attempted to apply these capabilities to the gdb binary itself to no avail. I did this as it seemed (as documented by the manpages that the "i" flag might allowed the debugee to inherit the capability from the debugger.
Is there something trivial I am missing or can this really not be done?
I run into same problem and at beginning I thought the same as above that maybe gdb is ignoring the executable's capability due to security reason. However, reading source code and even using eclipse debugging gdb itself when it is debugging my ext2fs-prog which opens /dev/sda1, I realize that:
gdb is no special as any other program. (Just like it is in the matrix, even the agents themselves they obey the same physical law, gravity etc, except that they are all door-keepers.)
gdb is not the parent process of debugged executable, instead it is grand father.
The true parent process of debugged executable is "shell", i.e. /bin/bash in my case.
So, the solution is very simple, apart from adding cap_net_admin,cap_net_raw+eip to gdb, you have also apply this to your shell. i.e. setcap cap_net_admin,cap_net_raw+eip /bin/bash
The reason that you have also to do this to gdb is because gdb is parent process of /bin/bash before create debugged process.
The true executable command line inside gdb is like following:
/bin/bash exec /my/executable/program/path
And this is parameter to vfork inside gdb.
For those who have the same problem, you can bypass this one by executing gdb with sudo.
A while ago I did run into the same problem. My guess is that running the debugged program with the additional capabilities is a security issue.
Your program has more privileges than the user that runs it. With a debugger a user can manipulate the execution of the program. So if the program runs under the debugger with the extra privileges then the user could use these privileges for other purposes than for which the program intended to use them. This would be a serious security hole, because the user does not have the privileges in the first place.
For those running GDB through an IDE, sudo-ing GDB (as in #Stéphane J.'s answer) may not be possible. In this case, you can run:
sudo gdbserver localhost:12345 /path/to/application
and then attach your IDE's GDB instance to that (local) GDBServer.
In the case of Eclipse CDT, this means making a new 'C/C++ Remote Application' debug configuration, then under the Debugger > Connection tab, entering TCP / localhost / 12345 (or whatever port you chose above). This lets you debug within Eclipse, whilst your application has privileged access.
I used #NickHuang's solution until, with one of system updates, it broke systemd services (too much capabilities on bash for systemd to start it or some such). Switched to leaving bash alone and instead pass a command to gdb to invoke the executable directly. The command is
set startup-with-shell off
OK, so I struggled a bit with this so I thought I'd combine answers and summarise.
The easy solution is just to sudo gdb as suggested but just be a bit careful. What you're doing here is running the debugged program as root. This may well cause it to operate differently than when you run it from the command line as a normal user. Could be a bit confusing. Not that I would EVER fall into this trap... Oopsies.
This will be fine if you're running the debugged program as root with sudo OR if the debugged program has the setuid bit set. But if the debugged program is running with POSIX capabilities (setcap / getcap) then you need to mirror these more granular permissions in bash and gdb as Nick Huang suggested rather than just brute forcing permissions with 'sudo'.
Doing anything else may lead you to a bad place of extreme learning.