[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dtrace
From: |
Björn Bidar |
Subject: |
Re: dtrace |
Date: |
Sat, 18 Jan 2025 23:11:05 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> If we don't want to grant root privileges to Emacs, how about doing
>> granting them to a separate sub-process, also running Emacs, perhaps
>> via the async package?
>
> To be generally useful, a DTrace consumer feature would probably have to
> let a user a D script plus some Lisp. The D script is required by
> libdtrace and specified the probe(s) to listen to, at a minimum. That's
> safe because D is safe. AFAIU, libdtrace then calls a user-supplied
> "chew" function when it has probe data. That would be some C function in
> Emacs. In that chew function, one would have to call Lisp to do
> something with the probes. So we'd execute arbitrary Lisp as root.
>
> I'm feeling very uncomfortable with that idea. Imagine someone
> distributes a package doing The Really Useful Thing using Emacs+DTrace,
> the installs it, enters his root password...
Would it possible to limit the scope with a wrapper in whatever
instances which has the capabilities? I don't know about dtrace
but for ptrace there is CAP_SYS_PTRACE.
Another option would be to use polkit to limit the access of the
wrapper, e.g. by asking pkexec to start the wrapper. Using capabilities
plus polkit without pkexec to only check for the permission would
require the least amount of permissions.
- Re: dtrace, (continued)
- Re: dtrace, Helmut Eller, 2025/01/16
- Re: dtrace, Gerd Möllmann, 2025/01/16
- Re: dtrace, Eli Zaretskii, 2025/01/16
- Re: dtrace, Gerd Möllmann, 2025/01/16
- Re: dtrace, Eli Zaretskii, 2025/01/16
- Re: dtrace, Gerd Möllmann, 2025/01/16
- Re: dtrace, Eli Zaretskii, 2025/01/16
- Re: dtrace, Gerd Möllmann, 2025/01/16
- Re: dtrace, Eli Zaretskii, 2025/01/16
- Re: dtrace, Gerd Möllmann, 2025/01/16
- Re: dtrace,
Björn Bidar <=
- Message not available
- Re: dtrace, Gerd Möllmann, 2025/01/18
- Re: dtrace, Björn Bidar, 2025/01/20
- Message not available
- Re: dtrace, Gerd Möllmann, 2025/01/20
- Re: dtrace, Richard Stallman, 2025/01/18
dtrace, Jordan Ellis Coppard, 2025/01/17