Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
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
add comment

2 Answers 2

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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