1. 04 Sep, 2017 9 commits
    • network: retrieve the host's veth device ifindex · 59574a77
      Christian Brauner authored
      - Retrieve the host's veth device ifindex in the host's network namespace.
      - Add a note why we retrieve the container's veth device ifindex in the host's
        network namespace.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • network: rework network creation · 96416905
      Christian Brauner authored
      - On unprivileged veth network creation have lxc-user-nic send the names of the
        veth devices and their respective ifindeces. The advantage of retrieving this
        information from lxc-user-nic is that we spare us sending around more stuff
        via the netpipe in start.c. Also, lxc-user-nic operates in both namespaces
        (the container's namespace and the hosts's namespace) via setns and so is
        guaranteed to retrieve the correct ifindex via if_nametoindex() which is an
        network namespace aware ioctl() call. While I'm pretty sure the ifindeces for
        veth devices are identical across network namespaces I'm weary to rely on
        this. We need the ifindexes to guarantee safe deletion of unprivileged
        network devices via lxc-user-nic later on since we use them to identify the
        network devices in their corresponding network namespaces.
      - Move the network device logging from the child to the parent. The child does
        not have all of the information about the network devices available only the
        few bits it actually needs to now. The monitor process is the only process
        that needs all this information.
      - The network creation code for privileged and unprivileged networks was
        previously mangled into one single function but at the same time some of the
        privileged code had additional functions that were called in other places in
        start.c. Let's divide and conquer and split out the privileged and
        unprivileged network creation into completely separate functions. This makes
        what's happening way more clear. This will also have no performance impact
        since either you are privileged and only execute the privileged network
        creation functions or you are unprivileged and only execute the unprivileged
        network creation functions.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • network: document all fields in struct lxc_netdev · 9a5df38f
      Christian Brauner authored
      This is menial work but I'll thank myself later... a lot.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • network: add ifindex field for host veth device · 1482e8e0
      Christian Brauner authored
      We should not just record the ifindex for the container's veth device but also
      for the host's veth device. This is useful when {configuring,deconfiguring}
      veth devices and becomes crucial when calling our lxc-user-nic setuid helper
      where we rely on the ifindex to make decisions about whether we are licensed to
      perform certain operations on the veth device in question.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • network: log veth_attr.pair and veth_attr.veth1 · dd208f1a
      Christian Brauner authored
      If the user specified lxc.net.[i].veth.pair attribute to request that the host
      side of a veth pair be given a specific name let's log it at the trace level.
      Otherwise, if the user didn't not specify lxc.net.[i].veth.pair veth_attr.veth1
      will contain the name of the host side veth device.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • lxc-user-nic: test privilege over netns on delete · 8ddde7ba
      Christian Brauner authored
      When lxc-user-nic is called with the "delete" subcommand we need to make sure
      that we are actually privileged over the network namespace for which we are
      supposed to delete devices on the host. To this end we require that path to the
      affected network namespace is passed. We then setns() to the network namespace
      and drop privilege to the caller's real user id. Then we try to delete the
      loopback interface which is not possible. If we are privileged over the network
      namespace this operation will fail with ENOTSUP. If we are not privileged over
      the network namespace we will get EPERM.
      
      This is the first part of the commit. As of now nothing guarantees that the
      caller does not just give us a random path to a network namespace it is
      privileged over.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
  2. 29 Aug, 2017 31 commits