Bug 2149384 - sudo disables coredumping
Summary: sudo disables coredumping
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Alejandro López
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-29 19:00 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2025-09-03 14:33 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-09-03 14:33:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 2149379 0 high CLOSED dnf5 crash with Assertion 'progress_bar != nullptr' 2023-02-03 13:03:46 UTC

Description Zbigniew Jędrzejewski-Szmek 2022-11-29 19:00:53 UTC
Description of problem:
I noticed this when looking into an issue with dnf5. Sudo set's ulimit core to 0, which effectively disables coredumps, making it hard to debug issues in compiled programs executed via sudo. I don't know if this is a question of configuration or defaults, but please make sudo not touch limits.

Version-Release number of selected component (if applicable):
sudo-1.9.11-4.p3.fc37.x86_64

How reproducible:
Deterministic.

Steps to Reproduce:
1. sudo grep core /proc/self/limits

Actual results:
$ sudo grep core /proc/self/limits
Max core file size        0                    0                    bytes     

Expected results:
$ sudo systemd-run -t grep core /proc/self/limits
Running as unit: run-u5051.service
Max core file size        unlimited            unlimited            bytes     

$ su -c 'grep core /proc/self/limits'
Password: 
Max core file size        unlimited            unlimited            bytes     

Additional info:
I suspect this might be related to old times where coredumps were written to the working directory and it made sense for sudo to disable coredumps. But now they are stored in a central location, so there is no reason to not allow them.

Comment 1 Ben Cotton 2023-02-07 15:00:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 2 Alejandro López 2025-09-03 14:33:50 UTC
From the sudoers(5) man page:

   Resource limits
       By default, sudoers uses the operating system's  native  method  of  setting  resource
       limits  for the target user.  On Linux systems, resource limits are usually set by the
       pam_limits.so PAM module.  On some BSD systems,  the  /etc/login.conf  file  specifies
       resource  limits  for the user.  On AIX systems, resource limits are configured in the
       /etc/security/limits file.  If there is no system mechanism to set  per-user  resource
       limits,  the  command  will  run  with  the same limits as the invoking user.  The one
       exception to this is the core dump file size, which is set by sudoers to 0 by default.
       Disabling core dumps by default makes it possible to avoid potential security problems
       where the core file is treated as trusted input.

       Resource limits may also be set in  the  sudoers  file  itself,  in  which  case  they
       override  those  set  by  the  system.   See  the  rlimit_as, rlimit_core, rlimit_cpu,
       rlimit_data, rlimit_fsize, rlimit_locks, rlimit_memlock, rlimit_nofile,  rlimit_nproc,
       rlimit_rss,  rlimit_stack  options described below.


Note You need to log in before you can comment on or make changes to this bug.