1. 24 Sep, 2017 33 commits
  2. 10 Sep, 2017 6 commits
    • console: clean tty state + return 0 on peer exit · 44a43f52
      LiFeng authored
      In the past, if the console client exited, lxc_console_cb_con return 1. And
      the lxc_poll will exit, the process will wait at waitpid. At this moment, the
      process could not handle any command (For example get the container state
      LXC_CMD_GET_STATE or stop the container LXC_CMD_STOP.).
      
      I think we should clean the tty_state and return 0 in this case. So, we can use
      the lxc-console to connect the console of the container. And we will not exit
      the function lxc_polland we can handle the commands by lxc_cmd_process
      
      Reproducer prior to this commit:
      - open a new terminal, get the tty device name by command tty /dev/pts/6
      - set lxc.console.path = /dev/pts/6
      - start the container and the ouptut will print to /dev/pts/6
      - close /dev/pts/6
      - try an operation e.g. getting state with lxc-ls and lxc-ls will hang
      
      Closes #1787.
      Signed-off-by: 's avatarLiFeng <lifeng68@huawei.com>
      Acked-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • conf: fix userns_exec_1() · 989351a2
      Christian Brauner authored
      A bit of context:
      userns_exec_1() is only used to operate based on privileges for the user's own
      {g,u}id on the host and for the container root's unmapped {g,u}id. This means
      we require only to establish a mapping from:
      - the container root {g,u}id as seen from the host -> user's host {g,u}id
      - the container root -> some sub{g,u}id
      
      This function however was buggy. It relied on some pointer pointing to the same
      memory, namely specific idmap entries in the idmap list in the container's
      in-memory configuration. However, due to a stupid mistake of mine, the pointers
      to be compared pointed to freshly allocated memory. They were never pointing to
      the intended memory locations. To reproduce what I'm talking about prior to
      this commit simply place:
      
          chb:999:1000000000
          chb:999:1
          chb:1000:1
      
      in /etc/sub{g,u}id then create a container which requests the following
      idmappings:
      
          lxc.idmap = u 0 999 999
          lxc.idmap = g 0 999 1000000000
      
      and start the container. What we *would expect* is for liblxc to establish the
      following mapping:
      
          newuidmap <pid> 0 999 999
          newgidmap <pid> 0 999 1000000000
      
      since all required mappings are present. Due to the buggy pointer comparisons
      what happened was:
      
          newuidmap <pid> 0 999 999 0 999 999
          newgidmap <pid> 0 999 1000000000 0 999 1000000000
      
      Let's fix this.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • conf: non-functional changes · eb4664ef
      Christian Brauner authored
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • console: non-functional change · 0887b061
      Christian Brauner authored
      Remove executable bit.
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • Merge pull request #1781 from brauner/stable-2.0 · f0ab9713
      Stéphane Graber authored
      stable 2.0: cherry-picks + delta reduction between master and stable 2.0
  3. 05 Sep, 2017 1 commit