All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: netdev@vger.kernel.org
Cc: David Miller <davem@davemloft.net>,
	Richard Cochran <richardcochran@gmail.com>,
	Miroslav Lichvar <mlichvar@redhat.com>,
	Patrick McHardy <kaber@trash.net>, Jiri Benc <jbenc@redhat.com>,
	stefan.sorensen@spectralink.com
Subject: Re: [PATCH net-next] macvlan: pass get_ts_info and SIOC[SG]HWTSTAMP ioctl to real device
Date: Wed, 17 Apr 2019 16:05:09 +0800	[thread overview]
Message-ID: <20190417061452.GA18865@dhcp-12-139.nay.redhat.com> (raw)
In-Reply-To: <20190320022333.3378-1-liuhangbin@gmail.com>

On Wed, Mar 20, 2019 at 10:23:33AM +0800, Hangbin Liu wrote:
> Similiar to commit a6111d3c93d0 ("vlan: Pass SIOC[SG]HWTSTAMP ioctls to
> real device") and commit 37dd9255b2f6 ("vlan: Pass ethtool get_ts_info
> queries to real device."), add MACVlan HW ptp support.
> 
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>

Hi all,

For this patch. Jiri mentioned that running two ptp4l/phc2sys instances on two
containers will not work. But I think the admin should avoid this scenario as
we should not run two phc2sys instances on the same real device. In NET_ADMIN
enabled containers, if a normal user which has mapped to root wants to run
ptp4l, the admin need either add the device specifically (--device=/dev/ptp1)
or give the container privileged permission (--privileged). So I think this
should not be a security problem.

On the other hand, Miroslav pointed that with NET_ADMIN enabled in container,
a normal user could be mapped to root and is able to change the real devices's
rx filter via ioctl on macvlan, which may affect the other ptp process on
host. ptp over vlan also has this issue, but macvlan is more frequently used
in container. To prevent this issue, here are some options:

1. limit ioctl SIOCSHWTSTAMP to only enabling timestamping and switching to
   more general filters. The limitation could be only in container and leave
   init_net free.
2. reject SIOCSHWTSTAMP in container.
3. revert the patch. The vlan part is too late to revert.

So what do you think? which one do you prefer?

Thanks
Hangbin

  parent reply	other threads:[~2019-04-17  8:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20  2:23 [PATCH net-next] macvlan: pass get_ts_info and SIOC[SG]HWTSTAMP ioctl to real device Hangbin Liu
2019-03-20 18:05 ` David Miller
2019-04-17  8:05 ` Hangbin Liu [this message]
2019-04-17 15:43   ` Richard Cochran
2019-04-17 18:59     ` Jiri Benc
2019-04-18  3:31       ` Richard Cochran
2019-04-18  6:10         ` Hangbin Liu
2019-04-18  8:05         ` Miroslav Lichvar
2019-04-23  4:18           ` Hangbin Liu
2019-04-23  8:31             ` Miroslav Lichvar
2019-04-23  9:15               ` Hangbin Liu
2019-04-23  9:32                 ` Miroslav Lichvar
2019-04-25 13:40                   ` Hangbin Liu
2019-05-06  7:34                     ` Hangbin Liu
2019-05-06 14:01                     ` Richard Cochran
2019-05-07  8:35                       ` Miroslav Lichvar
2019-05-08  1:41                         ` Hangbin Liu
2019-05-08 13:58                           ` Michal Kubecek

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=20190417061452.GA18865@dhcp-12-139.nay.redhat.com \
    --to=liuhangbin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jbenc@redhat.com \
    --cc=kaber@trash.net \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=stefan.sorensen@spectralink.com \
    /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.