On Sat, Jun 5, 2010 at 8:16 AM, Randy Solomonson <randy@solomonson.com> wrote:
> I have a system that uses C methods as functions in a Postgres
> database. When I try to run gdb with my user account I get this:
> ptrace: Operation not permitted
>
> It looks like a permission thing. It seemed to work when I ran gdb as
> the "postgres" user. I would like to continue running postgres as the
> "postgres" user and not have to su postgres when I want to debug. Can
> I somehow grant my user account "ptrace" permission for the process in
> question? Adding myself to the "postgres" group didn't seem to help.
>
> I found this on the ptrace man page:
>
> EPERM The specified process cannot be traced. This could be because
> the parent has insufficient privileges (the required capability
> is CAP_SYS_PTRACE); non-root processes cannot trace processes
> that they cannot send signals to or those running set-user-
> ID/set-group-ID programs, for obvious reasons. Alternatively,
> the process may already be being traced, or be init(8) (PID 1).
>
> So do I just need to give CAP_SYS_TRACE privileges to my user? If so, how?
This isn't really a PostgreSQL-specific question but more of a general
Linux admin question, and I confess I don't really know the answer. I
*think* that capabilities are more intended to be set on particular
executables, e.g. give ping the ability to open raw sockets without
making it setuid root, rather than to particular users, but I'm not
really sure.
In terms of PG development, I've found that it's much simpler to start
up a test instance of PG under my own user account and then do my
debugging from there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company