On 6/12/15 5:24 PM, Andy Lutomirski wrote:
>so what specifically you proposing?
>Use from_kuid(&init_user_ns,...) instead?
That seems reasonable to me. After all, you can't install one of
these probes from a non-init userns.
ok. will respin with that change.
--
To unsubscribe from this list:
On Fri, Jun 12, 2015 at 5:15 PM, Alexei Starovoitov wrote:
> On 6/12/15 5:03 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 4:55 PM, Alexei Starovoitov
>> wrote:
>>>
>>> On 6/12/15 4:47 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov
w
On 6/12/15 5:03 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:55 PM, Alexei Starovoitov wrote:
On 6/12/15 4:47 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov
wrote:
On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't
On Fri, Jun 12, 2015 at 4:55 PM, Alexei Starovoitov wrote:
> On 6/12/15 4:47 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov
>> wrote:
>>>
>>> On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't the returned uid ma
On 6/12/15 4:47 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov wrote:
On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't the returned uid match the
namespace of the task that installed the probe, not the task that's
being probed?
On Fri, Jun 12, 2015 at 4:38 PM, Alexei Starovoitov wrote:
> On 6/12/15 4:25 PM, Andy Lutomirski wrote:
>>
>> It's a dangerous tool. Also, shouldn't the returned uid match the
>> namespace of the task that installed the probe, not the task that's
>> being probed?
>
>
> so leaking info to unprivil
On 6/12/15 4:25 PM, Andy Lutomirski wrote:
It's a dangerous tool. Also, shouldn't the returned uid match the
namespace of the task that installed the probe, not the task that's
being probed?
so leaking info to unprivileged apps is the concern?
The whole thing is for root only as you know.
The
On Fri, Jun 12, 2015 at 4:23 PM, Alexei Starovoitov wrote:
> On 6/12/15 3:54 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 3:44 PM, Alexei Starovoitov
>> wrote:
>>>
>>> On 6/12/15 3:08 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov
w
On 6/12/15 3:54 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 3:44 PM, Alexei Starovoitov wrote:
On 6/12/15 3:08 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov
wrote:
eBPF programs attached to kprobes need to filter based on
current->pid, uid and other
On Fri, Jun 12, 2015 at 3:44 PM, Alexei Starovoitov wrote:
> On 6/12/15 3:08 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov
>> wrote:
>>>
>>> eBPF programs attached to kprobes need to filter based on
>>> current->pid, uid and other fields, so introduce helper
On 6/12/15 3:08 PM, Andy Lutomirski wrote:
On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov wrote:
eBPF programs attached to kprobes need to filter based on
current->pid, uid and other fields, so introduce helper functions:
u64 bpf_get_current_pid_tgid(void)
Return: current->tgid << 32 | cu
On Fri, Jun 12, 2015 at 2:40 PM, Alexei Starovoitov wrote:
> eBPF programs attached to kprobes need to filter based on
> current->pid, uid and other fields, so introduce helper functions:
>
> u64 bpf_get_current_pid_tgid(void)
> Return: current->tgid << 32 | current->pid
>
> u64 bpf_get_current_ui
eBPF programs attached to kprobes need to filter based on
current->pid, uid and other fields, so introduce helper functions:
u64 bpf_get_current_pid_tgid(void)
Return: current->tgid << 32 | current->pid
u64 bpf_get_current_uid_gid(void)
Return: current_gid << 32 | current_uid
bpf_get_current_com
13 matches
Mail list logo