Tracing with DTrace, when custom probe provider is running as regular user

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Tracing with DTrace, when custom probe provider is running as regular user

Kazik Chujwielki
Hello FreeBSD hackers. I have question about real world Dtrace tracing on our favourite platform.

Yesterday did enable dtrace for my builds of Erlang*, Php*, Node and Postgresql9x on my x86_64 11.1 system. It works very well in general, with one exception - I'm unable to get probes from software running as regular user.

So for example - I can launch Erlang 19.3.x REPL as root (`erl`), and do `dtrace -l | grep beam` - to see new provider with Erlang probes.. but if I launch exactly same Erlang REPL as regular user ("www" in my case) - I cannot see published probes when invoking `dtrace -l` (as root). I also can't invoke `dtrace -l` as regular user obviously.

Here's example on a single screenshot:


http://s.verknowsys.com/38a22eb93f473a0bac43e5e56f3d7f35.png

        ⇒ red lambda ⇒ root, gray lambda ⇒ regular user.
        ⇒ Erlang REPL running as root ⇒ probes are there.. but when as regular user ⇒ nothing


Issue is critical for tracing Postgresql which demands to run with NON privileged user, but in general launching any server software as root should be considered to be "harmful" / "a bad idea" right?

So question is - is there a way to work around this? I wish to be able to trace user software as root using dtrace. Is there a way to do it? I build whole system from source so I can even do custom patch if I'd know where to look :)


Thanks in advance!

--
Daniel (dmilith) Dettlaff

signature.asc (242 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tracing with DTrace, when custom probe provider is running as regular user

Matthew Seaman-5
On 09/04/2018 11:01, Daniel Dettlaff wrote:
> Issue is critical for tracing Postgresql which demands to run with
> NON  privileged user, but in general launching any server software as root
> should be considered to be "harmful" / "a bad idea" right?

The issue with allowing non-privileged users access to dtrace is the
risk of disclosing kernel memory.  Unfortunately blocking this access
means that using the UserSDT's from (for example) postgresql-server
running as the postgres user is not permitted.

> So question is - is there a way to work around this? I wish to be
> able to trace user software as root using dtrace. Is there a way to
> do it? I build whole system from source so I can even do custom patch
> if I'd know where to look :)
Actually, it all depends on the permissions on /dev/dtrace/* -- It's
fairly easy to. say, add a 'dtrace' group, change /dev/dtrace/helper to
be owned by root:dtrace and mode 0770 by tweaking /etc/devfs.rules:

[userdtrace=10]
add path dtrace/helper mode 0660 group dtrace

and adding devfs_system_ruleset="userdtrace" to /etc/rc.conf, and then
making the postgres or whatever other users your software runs as
members of group dtrace

        Cheers,

        Matthew
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Tracing with DTrace, when custom probe provider is running as regular user

Alexander Leidinger

Quoting Matthew Seaman <[hidden email]> (from Mon, 9 Apr 2018  
11:30:10 +0100):

> On 09/04/2018 11:01, Daniel Dettlaff wrote:
>> Issue is critical for tracing Postgresql which demands to run with
>> NON  privileged user, but in general launching any server software as root
>> should be considered to be "harmful" / "a bad idea" right?
>
> The issue with allowing non-privileged users access to dtrace is the  
> risk of disclosing kernel memory.  Unfortunately blocking this  
> access means that using the UserSDT's from (for example)  
> postgresql-server running as the postgres user is not permitted.

If I understand it right, the original poster was also not able to  
trace a non-root process with root-dtrace.
What's the reason for this?

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment