Is there gdb read only mode ?

Is there way I can restrict gdb level to read only. So I will not be able to modify current data in gdb.

Can gdbserver or any other tool help in this case?

  • 2
    That makes very little sense, and I think it can't be done at all. It looks like an X Y problem: You want to do something, and believe the way of doing so is though this, but don't tell us what you want to do in the first place. – vonbrand Mar 21 '13 at 8:03
  • @vonbrand As explained I want to keep history of all command user fired by going to production server. Including command fired inside application like gdb. Just want to keep history so I can see what a particular x developer done to fix the problem. – Vivek Goel Mar 21 '13 at 9:29
  • 1
    Wait. Back up. Did you say "attaching a debugger to the production server"? – Random832 Mar 21 '13 at 21:53
  • “I want to let my bloodhounds into the chicken coop to catch the fox's smell. But I don't want to allow them to eat a chicken.” So train them not to? – Gilles Mar 21 '13 at 22:33

If you don't want to allow devs to change things, why don't you give them a coredump ? A coredump is a dump of the memory map of the process. With this and the binary who generate the coredump, you can debug your application without running it (just need debug information). To generate a coredump, use gcore command.


There's no read-only mode for gdb, and gdb isn't the only way to debug a program anyway (it has no special permissions). Gdb uses ptrace underneath, and the ptrace permissions are all-or-nothing.

There are security frameworks that restrict the use of ptrace. For example, Recent Ubuntu versions restrict ptrace to the parent process by default. But these restrictions are about who can use ptrace on what process, not what ptrace commands are permitted. I'm not aware of a framework that has fined-grained permissions that distinguish between ptrace commands.

You seem to want to allow developers to investigate problems live on production servers, without letting them modify the way these systems behave. A solution to this problem is to run all servers in virtual machines. If a problem occurs, make a snapshot of the virtual machine, copy it out, and let the developers work from the snapshot (disconnected from the network). That even makes the developers' work easier since they can restart their debugging as many times as they like, from the saved snapshot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.