解决docker使用GDB,无法进入断点的问题

解决docker使用GDB,无法进入断点的问题

本文主要介绍如何解决docker在使用GDB时无法进入断点的问题。有很好的参考价值，希望对大家有所帮助。来和边肖一起看看吧。

问题

Gdb在docker中运行，命中了一个断点，但是无法进入断点。

原因

Docker为了保证主机的安全性，docker有很多安全设置，包括ASLR(地址空间布局随机化)，即docker中的内存地址与主机中的不同。

ASLR将导致GDB，一个依赖于地址的程序，无法正常工作。

解决方法

使用docker的超级特权和add-privileged(两条水平线，markdown语法

比如:

码头工人运行-特权……

GDB可以正常工作。

超级特权将关闭许多安全设置，因此您可以充分利用docker功能。

比如可以在docker里再打开docker，呵呵。

补充知识:Dockerplace:不允许 *** 作。处理方法

docker中的Gdb在调试流程时会报错:

(gdb)附加30721

附加到进程30721

ptrace:不允许 *** 作。

原因是ptrace被Docker默认禁止。考虑到应用分析的需要，有几种方法可以解决:

1。关闭seccomp

dockerrun-security-optseccomp=unconfined

2。采用超级权限模式

码头运行-特权

3。仅开放ptrace限制

dockerrun-cap-addsys_ptrace

当然，从安全角度来说，如果只是想用gdb进行调试，建议使用第三种。

安全计算模式(seccomp)是一个Linux内核函数，可以用来限制容器中可用的 *** 作。

Docker的默认seccomp配置文件是一个白名单，它指定了允许的调用。

下表列出了由于不在白名单中而被有效阻止的重要(但不是全部)系统调用。此表包含每个系统调用被阻塞的原因。

系统调用 描述 acct Accountingsyscall可以让容器禁用自己的资源限制或进程记帐。也由CAP_SYS_PACCT选通。 add_key 防止容器使用没有命名空间的内核密匙环。 adjtimex 与clock_settime和settimeofday类似，时间/日期没有命名空间。也由CAP_SYS_TIME门控。 bpf 拒绝将潜在的持久bpf程序加载到内核中，该程序已经被CAP_SYS_ADMIN控制。 clock_adjtime 时间/日期没有命名空间。也由CAP_SYS_TIME门控。 clock_settime 时间/日期没有命名空间。也由CAP_SYS_TIME门控。 clone 拒绝克隆新的命名空间。除CLONE_USERNS外，CLONE_*标志也由CAP_SYS_ADMIN选通。 create_module 拒绝内核模块上的 *** 作和功能。过时了。也由CAP_SYS_MODULE选通。 delete_module 拒绝内核模块上的 *** 作和功能。也由CAP_SYS_MODULE选通。 finit_module 拒绝内核模块上的 *** 作和功能。也由CAP_SYS_MODULE选通。 get_kernel_syms 拒绝检索导出的内核和模块符号。过时了。 修改内核内存和NUMA设置的get_mempolicy Syscall。已经由CAP_SYS_NICE门控。 init_module 拒绝内核模块上的 *** 作和功能。也由CAP_SYS_MODULE选通。 ioperm 防止容器修改内核I/O特权级别。已经由CAP_SYS_RAWIO门控。 iopl 防止容器修改内核I/O特权级别。已经由CAP_SYS_RAWIO门控。 kcmp 限制进程检查功能，已被删除CAP_PTRACE阻止。 kexec_file_load kexec_load的姊妹系统调用，做同样的事情，只是参数略有不同。也由CAP_SYS_BOOT选通。 kexec_load 拒绝为以后的执行加载新的内核。也由CAP_SYS_BOOT选通。 keyctl 阻止容器使用内核密匙环，它没有命名空间。 lookup_dcookie Tracing/profilingsyscall，这可能会泄漏主机上的大量信息。也由CAP_SYS_ADMIN门控。 mbind Syscall修改内核内存和NUMA设置。已经由CAP_SYS_NICE门控。 mount 拒绝装载，已由CAP_SYS_ADMIN控制。 move_pages 修改内核内存和NUMA设置的系统调用。 name_to_handle_at 姊妹系统调用open_by_handle_at。已经由CAP_SYS_NICE门控。 nfsservctl 拒绝与内核nfs守护进程进行交互。从Linux3.1开始过时。 open_by_handle_at 旧集装箱漏装原因。也由CAP_DAC_READ_SEARCH选通。 perf_event_open 跟踪/分析syscall，这可能会泄漏主机上的大量信息。 personality 阻止容器启用BSD仿真。本质上并不危险，但是测试不充分，可能会有很多内核漏洞。 pivot_root Denypivot_root，应该是特权 *** 作。 process_vm_readv 限制进程检查功能，已被删除CAP_PTRACE阻塞。 process_vm_writev 限制进程检查功能，已被删除CAP_PTRACE阻止。 ptrace 跟踪/分析syscall，这可能会泄漏主机上的大量信息。已被删除CAP_PTRACE阻止。 query_module 拒绝内核模块上的 *** 作和功能。过时了。 quotactl Quotasyscall可以让容器禁用它们自己的资源限制或进程记帐。也由CAP_SYS_ADMIN门控。 重新启动 不要让容器重新启动主机。也由CAP_SYS_BOOT选通。 request_key 阻止容器使用没有命名空间的内核密匙环。 set_mempolicy 修改内核内存和NUMA设置的Syscall。已经由CAP_SYS_NICE门控。 setns 拒绝将线程与命名空间相关联。也由CAP_SYS_ADMIN门控。 settimeofday 时间/日期没有命名空间。也由CAP_SYS_TIME门控。 socket，socketcall 用于发送或接收数据包以及其他套接字 *** 作。除了通信域AF_UNIX、AF_INET、AF_INET6、AF_NETLINK和AF_PACKET之外，所有socket和socketcall调用都被阻塞。 stime 时间/日期没有命名空间。也由CAP_SYS_TIME门控。 swapon 拒绝开始/停止交换到文件/设备。也由CAP_SYS_ADMIN门控。 swapoff 拒绝开始/停止交换到文件/设备。也由CAP_SYS_ADMIN门控。 sysfs 过时的syscall。 _sysctl 已过时，替换为/proc/sys。 umount 应该是特权 *** 作。也由CAP_SYS_ADMIN门控。 umount2 应该是特权 *** 作。也由CAP_SYS_ADMIN门控。 unshare 拒绝为进程克隆新的命名空间。也由CAP_SYS_ADMIN控制，但非共享用户除外。 uselib 与共享库相关的较旧的syscall，长时间未使用。 userfaultfd 用户空间页面错误处理，主要用于进程迁移。 ustat 过时的系统调用。 内核x86实模式虚拟机中的vm86 。也由CAP_SYS_ADMIN门控。 内核x86实模式虚拟机中的vm86old 。也由CAP_SYS_ADMIN门控。

以上docker使用GDB无法进入断点的问题是边肖分享的全部内容。希望给大家一个参考，多多支持我们。