All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Urs Thuermann <urs@isnogud.escape.de>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Oliver Hartkopp <oliver@hartkopp.net>,
	Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Subject: Re: [PATCH 3/7] CAN: Add raw protocol
Date: Wed, 19 Sep 2007 10:34:58 +0200	[thread overview]
Message-ID: <46F0DF32.9020707@trash.net> (raw)
In-Reply-To: <ygfbqbzzls5.fsf@janus.isnogud.escape.de>

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
> 
> 
>>>+config CAN_RAW_USER
>>>+	bool "Allow non-root users to access Raw CAN Protocol sockets"
>>>+	depends on CAN_RAW
>>
>>Would it be much more trouble for userspace to use capabilities for
>>this? This would allow userspace to always know what to expect, I
>>don't think distributions will enable this option (which might again
>>not matter since they're probably rarely used in cars :)).
> 
> 
> First, it's not only used in cars but also in other embedded and
> automation contexts :-)
> 
> In fact, we already check capabilities in af_can.c:can_create() like
> this
> 
>         if (cp->capability >= 0 && !capable(cp->capability))
>                 return -EPERM;
> 
> Each protocol implementation can set cp->capability to -1 so that all
> users can open sockets without any restriction or to some capability,
> typically CAP_NET_RAW.  In raw.c it is done so
> 
> 	#ifdef CONFIG_CAN_RAW_USER
> 	#define RAW_CAP (-1)
> 	#else
> 	#define RAW_CAP CAP_NET_RAW
> 	#endif
> 
> I also didn't love this configure option very much when we added it.
> But in embedded systems it is often not much of a problem to let
> anybody access raw sockets, since there are no "normal" users.  This
> is the reason for the configure option.  I haven't yet looked into
> capabilities and their inheritance between process in detail.	Would
> it be easy to let all user space run with CAP_NET_RAW?  What if some
> process calls setuid() or execve()s a set-uid program?  Will
> capabilities be retained?


If its in the inheritable set, I believe it is retained. I mainly
don't like it because I believe permission checks shouldn't depend
on config option, this makes it harder for userspace to know what
to expect. But keep it if you must.

>>>+static int raw_notifier(struct notifier_block *nb,
>>>+			unsigned long msg, void *data)
>>>+{
>>>+	struct net_device *dev = (struct net_device *)data;
>>>+	struct raw_sock *ro = container_of(nb, struct raw_sock, notifier);
>>>+	struct sock *sk = &ro->sk;
>>>+
>>>+	DBG("msg %ld for dev %p (%s idx %d) sk %p ro->ifindex %d\n",
>>>+	    msg, dev, dev->name, dev->ifindex, sk, ro->ifindex);
>>>+
>>>+	if (dev->nd_net != &init_net)
>>>+		return NOTIFY_DONE;
>>>+
>>>+	if (dev->type != ARPHRD_CAN)
>>>+		return NOTIFY_DONE;
>>>+
>>>+	if (ro->ifindex != dev->ifindex)
>>>+		return NOTIFY_DONE;
>>
>>
>>Wouldn't that be a BUG()?
> 
> 
> Would it?  I think there is only one netdev_chain, not one per
> device.  I.e. our raw_notifier() gets all events on any netdevice, not
> only the ones we're interested in, for example also eth0.  And I think
> we should silently ignore these events by returning NOTIFY_DONE.  Am I
> missing something here?


No, I misunderstood the code.

  reply	other threads:[~2007-09-19  8:41 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-17 10:03 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #6 Urs Thuermann
2007-09-17 10:03 ` [PATCH 1/7] CAN: Allocate protocol numbers for PF_CAN Urs Thuermann
2007-09-18 13:31   ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-09-17 15:50   ` Paul E. McKenney
2007-09-18 13:31   ` Patrick McHardy
2007-09-18 14:54     ` Urs Thuermann
2007-09-18 15:07       ` Patrick McHardy
2007-09-18 21:20     ` Urs Thuermann
2007-09-19  8:27       ` Patrick McHardy
2007-09-20  8:53         ` Urs Thuermann
2007-09-20 10:33           ` Patrick McHardy
2007-09-20 11:30             ` Urs Thuermann
2007-09-20 11:43               ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-09-18 14:13   ` Patrick McHardy
2007-09-18 21:49     ` Urs Thuermann
2007-09-19  8:34       ` Patrick McHardy [this message]
2007-09-17 10:03 ` [PATCH 4/7] CAN: Add broadcast manager (bcm) protocol Urs Thuermann
2007-09-17 10:03 ` [PATCH 5/7] CAN: Add virtual CAN netdevice driver Urs Thuermann
2007-09-18 15:02   ` Patrick McHardy
2007-09-18 22:24     ` Urs Thuermann
2007-09-19  6:26       ` Oliver Hartkopp
2007-09-19  8:41       ` Patrick McHardy
2007-09-17 10:03 ` [PATCH 6/7] CAN: Add maintainer entries Urs Thuermann
2007-09-17 10:03 ` [PATCH 7/7] CAN: Add documentation Urs Thuermann
2007-09-17 17:30   ` Randy Dunlap
2007-09-17 20:22     ` Urs Thuermann
2007-09-17 20:37       ` Thomas Gleixner
2007-09-17 20:49         ` Urs Thuermann
2007-09-17 22:57           ` Randy Dunlap
2007-09-17 23:19             ` Urs Thuermann
2007-09-18  6:51           ` Bill Fink
2007-09-18  7:20             ` Urs Thuermann
  -- strict thread matches above, loose matches on Subject: below --
2007-11-16 15:02 [PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25, update Urs Thuermann
2007-11-16 15:02 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-11-14 12:13 [PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25 Urs Thuermann
2007-11-14 12:13 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-10-05 10:49 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #10 Urs Thuermann
2007-10-05 10:49 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-10-02 13:10 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #9 Urs Thuermann
2007-10-02 13:10 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-10-02 14:30   ` Arnaldo Carvalho de Melo
2007-10-02 14:53     ` Oliver Hartkopp
2007-10-04 11:52     ` Urs Thuermann
2007-09-25 12:20 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #8 Urs Thuermann
2007-09-25 12:20 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-09-20 18:43 [PATCH 0/7] CAN: Add new PF_CAN protocol family, try #7 Urs Thuermann
2007-09-20 18:43 ` [PATCH 3/7] CAN: Add raw protocol Urs Thuermann
2007-09-21 12:49   ` Patrick McHardy
2007-09-21 21:05     ` Urs Thuermann
2007-09-22 11:02       ` Patrick McHardy
2007-08-04  2:06 [patch 0/7] CAN: Add new PF_CAN protocol family, try #5 Urs Thuermann
2007-08-04  2:07 ` [patch 3/7] CAN: Add raw protocol Urs Thuermann
2007-06-22  3:44 [patch 0/7] CAN: Add new PF_CAN protocol family, try #3 Urs Thuermann
2007-06-22  3:44 ` [patch 3/7] CAN: Add raw protocol Urs Thuermann
2007-05-30 13:11 [patch 0/7] CAN: Add new PF_CAN protocol family, update Urs Thuermann
2007-05-30 13:11 ` [patch 3/7] CAN: Add raw protocol Urs Thuermann
2007-05-16 14:51 [patch 0/7] CAN: Add new PF_CAN protocol family Urs Thuermann
2007-05-16 14:51 ` [patch 3/7] CAN: Add raw protocol Urs Thuermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46F0DF32.9020707@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=oliver.hartkopp@volkswagen.de \
    --cc=oliver@hartkopp.net \
    --cc=tglx@linutronix.de \
    --cc=urs@isnogud.escape.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.