[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AB1355C3-08FA-4A96-A5E5-56FCF35D4921@oracle.com>
Date: Sat, 1 Apr 2023 18:32:31 +0000
From: Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
To: Christian Brauner <brauner@...nel.org>
CC: Jakub Kicinski <kuba@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"zbr@...emap.net" <zbr@...emap.net>,
"johannes@...solutions.net" <johannes@...solutions.net>,
"ecree.xilinx@...il.com" <ecree.xilinx@...il.com>,
"leon@...nel.org" <leon@...nel.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"socketcan@...tkopp.net" <socketcan@...tkopp.net>,
"petrm@...dia.com" <petrm@...dia.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
Subject: Re: [PATCH v1 2/5] connector/cn_proc: Add filtering to fix some bugs
> On Mar 14, 2023, at 1:38 AM, Christian Brauner <brauner@...nel.org> wrote:
>
> On Mon, Mar 13, 2023 at 05:24:41PM -0700, Jakub Kicinski wrote:
>> On Fri, 10 Mar 2023 14:15:44 -0800 Anjali Kulkarni wrote:
>>> diff --git a/include/linux/connector.h b/include/linux/connector.h
>>> index 487350bb19c3..1336a5e7dd2f 100644
>>> --- a/include/linux/connector.h
>>> +++ b/include/linux/connector.h
>>> @@ -96,7 +96,11 @@ void cn_del_callback(const struct cb_id *id);
>>> *
>>> * If there are no listeners for given group %-ESRCH can be returned.
>>> */
>>> -int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 group, gfp_t gfp_mask);
>>> +int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid,
>>> + u32 group, gfp_t gfp_mask,
>>> + int (*filter)(struct sock *dsk, struct sk_buff *skb,
>>> + void *data),
>>> + void *filter_data);
>>
>> kdoc needs to be extended
>
> just a thought from my side. I think giving access to unprivileged users
> will require a little thought as that's potentially sensitive.
>
> If possible I would think that the patches that don't lead to a
> behavioral change should go in completely independently and then we can
> discuss the non-root access change.
Hi Christian,
Could you take a look at v4 and let me know your thoughts, so we can start a discussion on that thread? Do we need more filtering based on user ID /other parameters for exit status? Can we allow just non-zero notification (not the exact exit status but just whether it was a 0 or a non-zero exit) be available to non-root users?
Do other folks have any more comments/suggestions?
Thanks
Anjali
Powered by blists - more mailing lists