On 9/13/25 6:02 PM, Mark Wielaard wrote:
Hi Jan,
On Fri, Sep 12, 2025 at 06:30:59PM +0200, Jan Drögehoff wrote:
Some addititional info and bugzilla links to read up on prior history:
- the upstream kernel believes that having it on by default is best
- the fedora kernel maintainers at the time (2015) did not want to
maintain a patch
- turning off yama was also rejected
- the elfutils package added the config as a bugfix with no change
proposal or fesco approval I could find despite having system-wide
ramifications
All true, but done under time pressure because at the time the broken
kernel config had already shipped (or was about to). The kernel
doesn't normally post change proposals (even if they change a config
like here that breaks user space). And the kernel does major rebases
across distro versions. Ideally if there had been time this was
changed upstream or with a proper kernel or systemd config. The
current solution just returns the status quo, unbreaking user
space. And is also what is done by elfutils upstream and in other
distros. I don't think anybody did anything to deliberately break
packages or avoid change proposal processes.
True, but from what I can tell only developers complained with real
users either being unaffected or not vocal about it.
I'll follow up more on the distro part below but I looked into the
elfutils config and it seems to be put in place by you in response to
the whole Fedora discussion so I wouldn't count it as an independent
solution.
https://github.com/roolebo/elfutils/commit/d950fcd511c79193ff1ed9a994826d6bb61e77c1
What should be done is an evaluation of how the config affects regular
users and if it doesn't how things can be setup for developers to have a
relatively painless experience, e.g. a package that disables the config
that relevant packages can depend on.
Some personal thoughts:
- Other distros already default to the ptrace protection to 1 and
seem to work without any well known problems, what would break on
Fedora? (besides arbitrary debugging setups which I consider to be
invalid arguments)
Probably depends on the target audience, both other distros I use
besides Fedora, Debian and Alma seem to default to the same setup.
I've gone and looked into what distros use as a default or closest to
default:
- Debian: 0 (same situation as fedora, turned off after demand
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740)
- Ubuntu: 1 (intentionally enabled
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection)
- Void Linux: 1 (explicitly set
https://github.com/void-linux/void-packages/commit/a8fa975f9fb60752eb5d03bc2c19132141d651e9)
- Gentoo: 1 (YAMA is pre-enabled in the bin kernel and kept as the default)
- Arch: 1 (intentionally enasbled
https://wiki.archlinux.org/title/Security#ptrace_scope, set to 2 with
hardened config)
Is there any overlap in the target audiences here? Even distros that are
generally considered to be for power-users have it enabled by default.
- tools like gdb or strace are most often than not used on child
processes that the tool itself spawned
I believe a lot of people run tools like strace, pstack or eu-stack to
quickly see where and how their own (already running) processes are
stuck. At least I do.
This is one use case but usually one that happens less often than
something like debugging during development.
There is also the use-case also mentioned in this thread where a process
needs prior setup by something else and thus isn't feasible to be
debugged by simply running it (e.g. a CGI script) but I think in both
cases it should be trivial to install a package once that installs the
config to disable it or run a command to override it.
Cheers,
Mark
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
