This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: don't run elfutils as root in ABRT
- From: Mark Wielaard <mjw at redhat dot com>
- To: Adam Šulc <sulcadam12 at gmail dot com>
- Cc: elfutils-devel at sourceware dot org, mhabrnal at redhat dot com, msuchy at redhat dot com
- Date: Tue, 07 Mar 2017 13:52:12 +0100
- Subject: Re: don't run elfutils as root in ABRT
- Authentication-results: sourceware.org; auth=none
- References: <CAJdWHfgzF1JxTBzHTW3ozxqiaBxJ50dY3LdU6W3mfOtaqdy=DQ@mail.gmail.com>
Hi Adam,
On Tue, 2017-03-07 at 13:39 +0100, Adam Šulc wrote:
> I work on ABRT improvement in order to increase security related to core
> backtrace generating using elfutils library.
> Here is a short description of my problem:
>
> Goal is to not call base code in elfutils and gdb functions under root.
> If you are more interested you can read more there:
> https://github.com/abrt/abrt/issues/890
>
> We need root for opening /proc files only.
> First, we open these files under root,
> then we drop capabilities & privileges and finally, we generate
> core_backtrace.
If you drop priviliges to the uid of the process then you should still
be able to open /proc files for that process/user. That seems the
simplest solution.
> We have one problem, that we need to pass the opened /proc file to this
> function:
> dwfl_linux_proc_report (Dwfl *dwfl, pid_t pid)
> Because this function opens the /proc file itself, thus it is hard coded
> and we cannot pass our /proc file pointer:
> https://github.com/abrt/satyr/blob/master/lib/core_unwind_elfutils.c#L251
> So we dont know how to pass the opened file to this function.
>
> Do you have any idea how to pass the open file descriptor into the
> function? Or what is the best way how to achieve this?
See the function right after dwfl_linux_proc_report in libdwfl.h:
/* Call dwfl_report_module for each file mapped into the address space of PID.
Returns zero on success, -1 if dwfl_report_module failed,
or an errno code if opening the proc files failed. */
extern int dwfl_linux_proc_report (Dwfl *dwfl, pid_t pid);
/* Similar, but reads an input stream in the format of Linux /proc/PID/maps
files giving module layout, not the file for a live process. */
extern int dwfl_linux_proc_maps_report (Dwfl *dwfl, FILE *);
It does slightly less because it doesn't know the running process pid,
but might do enough for your use case. But I think just dropping
privileges to the uid of the process is easier.
Cheers,
Mark