Created attachment 14675 [details] Patch to fallback to trying direct if unable to enter target's namespace due to insufficient permissions I ran into a regression trying to attach to and debug a hung process on the one of the Canadian super computer system. Newer gdbs kept giving a confusing error message about operation not permitted when opening the executable and refused to load the symbol information while older ones worked okay. [tyson@gra120 ~]$ gdb -p 26848 GNU gdb (Gentoo 9.1 vanilla) 9.1 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 26848 [New LWP 26849] [New LWP 26850] [New LWP 26852] warning: "target:/project/6001152/issm5/bin/issm.exe": could not open as an executable file: Operation not permitted. warning: `target:/project/6001152/issm5/bin/issm.exe': can't open to read symbols: Operation not permitted. warning: Could not load vsyscall page because no executable was specified 0x00002b2741a5d64d in ?? () (gdb) After a lot of digging around and the help of my colleague Bart Oldeman compiling and trying a lot of different gdb versions, we eventually traced it down to the introduction of the linux namespace code in 7.10. This code seems to assumes that different namespace automatically mean there are containers and that target paths will not valid outside of their container namespace. This isn't universally true. In the super computer world, the SLURM scheduler runs jobs in a separate namespaces and cgroups for reasons of resource control. The target paths are perfectly valid outside of the target, and sysadmins are not happy about the idea of handing out extra capabilities. I have done up a short patch and attached it to restore the previous behaviour of just directly trying to use the targets paths as a fallback if setns fails due to lacking capabilities. This resolves the issue for us. Possibly a warning should be issued, so container users know they need to run with elevated capabilities, but, not being familiar with the gdb code base, I wasn't clear on how best that would be done. Thanks! Tyson
I just saw this bug today. gdb doesn't normally review patches in bugzilla. Instead there is a mailing list, for full details see https://sourceware.org/gdb/wiki/ContributionChecklist
Thanks. Had actually forgotten all about this. Glad you came across it. Still applies cleanly on top of master, so I'll fire it off to the email list.