There are some split-debugs in e.g. /usr/lib*/debug/usr/bin/* which are only root readable. So useless for non-root debugging. This shouldn't be. $ find . ! -perm -g=r ./sbin/mount.nfs.debug ./sbin/unix_chkpwd.debug ./usr/sbin/ssmtp.debug ./usr/sbin/pbs_iff.debug ./usr/lib32/misc/glibc/pt_chown.debug ./usr/bin/man.debug ./usr/bin/ksu.debug ./usr/bin/chsh.debug ./usr/bin/chfn.debug ./usr/bin/lppasswd.debug ./usr/bin/expiry.debug ./usr/bin/pkexec.debug ./usr/bin/sudo.debug ./usr/bin/screen.debug ./usr/bin/mpdroot.debug ./usr/bin/write.debug ./usr/bin/sudoedit.debug ./usr/bin/fcrondyn.debug ./usr/bin/gpasswd.debug ./usr/bin/fcronsighup.debug ./usr/bin/Xorg.debug ./usr/bin/newgrp.debug ./usr/bin/chage.debug ./usr/bin/locate.debug ./usr/bin/fcrontab.debug ./usr/bin/cpufreq-selector.debug ./usr/bin/dotlockfile.debug ./usr/lib64/misc/utempter/utempter.debug ./usr/lib64/misc/glibc/pt_chown.debug ./usr/lib64/misc/ssh-keysign.debug ./usr/libexec/dbus-daemon-launch-helper.debug ./usr/libexec/camel-lock-helper-1.2.debug ./usr/libexec/polkit-1/polkit-agent-helper-1.debug ./usr/libexec/gnome-pty-helper.debug ./usr/libexec/lockspool.debug ./bin/su.debug ./bin/passwd.debug ./bin/umount.debug ./bin/mount.debug ./bin/ping.debug
Aren't these suid binaries? I guess installing debugs for them world readable might be considered a security risk.
(In reply to comment #1) > Aren't these suid binaries? I guess installing debugs for them world readable > might be considered a security risk. > I cannot judge it, but assume a debug case for sudo. This only makes sense as user not as root.
Doesn't it make sense for the *.debug files to inherit permissions from the original files that they were split from? Would it be responsible to do anything different from this?
So what to do in case of sudo? $ ll /usr/bin/sudo /usr/lib64/debug/usr/bin/sudo.debug ---s--x--x 2 root root 167K Sep 24 19:25 /usr/bin/sudo* -rw------- 2 root root 336K Sep 24 19:25 /usr/lib64/debug/usr/bin/sudo.debug If I want to debug it as user, I'll end up with /usr/bin/sudo: Permission denied. $ gdb /usr/bin/sudo GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 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". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... /usr/bin/sudo: Permission denied. (gdb)
I was going to suggest to set FEATURES=-sfperms, but then I realized the sfperms code runs after pkg_preinst, which is well after the split-debug code which runs after src_install. Apparently the strict permissions are coming from the ebuilds. We might be able to solve this by providing a way for you to have more control over the permissions setting policy. Bug #141619 is related.
jlec, could you try manually setting a+r and checking whether gdb will allow debugging in the first place?
(In reply to comment #6) > jlec, could you try manually setting a+r and checking whether gdb will allow > debugging in the first place? > No, still getting the permission denied error.
