From: Pedro Alves <palves@redhat.com>
To: Jon Ringle <jon@ringle.org>
Cc: gdb-patches@sourceware.org, Jon Ringle <jringle@gridpoint.com>
Subject: Re: [PATCH v2] gdbserver: linux_low: elf_64_file_p cache results
Date: Thu, 24 Aug 2017 14:42:00 -0000 [thread overview]
Message-ID: <b0b54d2c-49d4-a8a9-dd6a-458a48039332@redhat.com> (raw)
In-Reply-To: <CAMwGMjwPzZd-P8KRrjY6-mowkPbOLX+JTz-yL2W=N63q7BkzzA@mail.gmail.com>
On 08/24/2017 03:14 PM, Jon Ringle wrote:
> On Thu, Aug 24, 2017 at 5:26 AM, Pedro Alves <palves@redhat.com> wrote:
>> Hi Jon,
>>
>> On 08/24/2017 05:45 AM, jon@ringle.org wrote:
>>
>>> The problem lied in the fact that the function elf_64_file_p() (call on
>>> line 7184), was returning -1 because it could not open the file (with errno
>>> set to EACCESS). This was because the inferior's code was dropping root
>>> privileges and no longer was able to read the file.
>>
>> I feel like I'm missing something. If it's the inferior that
>> is dropping privileges, how can that affect gdbserver? It's gdbserver
>> that opens the file, not the inferior.
>>
>> It'd be nice to have a testcase for this. Would it be possible to come
>> up with a small reproducer?
>>
>
> I learned something while coming up with a small reproducer. The real
> program I'm debugging is a systemd service and has a
> CapabilityBoundingSet. The CapabilityBoundingSet turns out to be a
> crucial point for reproducing.
>
> I setup a systemd service:
> $ cat /lib/systemd/system/droproot-test.service
> [Unit]
> Description=gdbserver droproot test service
>
> [Service]
> Type=simple
> ExecStart=/home/jringle/build/gdbserver/gdbserver :5555
> /home/jringle/git/droproot-test/droproot-test jringle
> Restart=on-success
> CapabilityBoundingSet=CAP_SETGID CAP_SETUID
OK, I don't know much about this, but it sounds like
without that, your "droproot" test wouldn't be able
to call setgid/setuid successfully to change to the
"jringle" user.
I'm still mystified about why can't gdbserver read
the file after "droproot" has changed user.
I assume gdbserver is running as root? Why wouldn't
a gdbserver running as root be able to read "jringle"'s
/proc file?
Does CAP_PTRACE make a difference?
I have to wonder whether there's a better way to do this..
gdbserver needs to read other /proc files, some not cacheable.
I fear that you may have run into just one case so far, and
that we may run into problems if we take this route.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-08-24 14:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 4:45 jon
2017-08-24 9:27 ` Pedro Alves
2017-08-24 14:15 ` Jon Ringle
2017-08-24 14:42 ` Pedro Alves [this message]
2017-08-24 14:53 ` Pedro Alves
2017-08-24 15:00 ` Jon Ringle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0b54d2c-49d4-a8a9-dd6a-458a48039332@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jon@ringle.org \
--cc=jringle@gridpoint.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox