moby/libnetwork/sandbox_externalkey_unix.go

181 lines
4.5 KiB
Go
Raw Normal View History

//go:build linux || freebsd
package libnetwork
import (
"context"
"encoding/json"
"flag"
"fmt"
"io"
"net"
"os"
"path/filepath"
"github.com/containerd/containerd/log"
"github.com/docker/docker/libnetwork/types"
"github.com/docker/docker/pkg/reexec"
"github.com/docker/docker/pkg/stringid"
"github.com/opencontainers/runtime-spec/specs-go"
)
const (
execSubdir = "libnetwork"
defaultExecRoot = "/run/docker"
success = "success"
)
func init() {
// TODO(thaJeztah): should this actually be registered on FreeBSD, or only on Linux?
reexec.Register("libnetwork-setkey", processSetKeyReexec)
}
type setKeyData struct {
ContainerID string
Key string
}
// processSetKeyReexec is a private function that must be called only on an reexec path
// It expects 3 args { [0] = "libnetwork-setkey", [1] = <container-id>, [2] = <short-controller-id> }
// It also expects specs.State as a json string in <stdin>
// Refer to https://github.com/opencontainers/runc/pull/160/ for more information
// The docker exec-root can be specified as "-exec-root" flag. The default value is "/run/docker".
func processSetKeyReexec() {
libnetwork: processSetKeyReexec() remove defer() Split the function into a "backing" function that returns an error, and the re-exec entrypoint, which handles the error to provide a more idiomatic approach. This was part of a larger change accross multiple re-exec functions (now removed). For history's sake; here's the description for that; The `reexec.Register()` function accepts reexec entrypoints, which are a `func()` without return (matching a binary's `main()` function). As these functions cannot return an error, it's the entrypoint's responsibility to handle any error, and to indicate failures through `os.Exit()`. I noticed that some of these entrypoint functions had `defer()` statements, but called `os.Exit()` either explicitly or implicitly (e.g. through `logrus.Fatal()`). defer statements are not executed if `os.Exit()` is called, which rendered these statements useless. While I doubt these were problematic (I expect files to be closed when the process exists, and `runtime.LockOSThread()` to not have side-effects after exit), it also didn't seem to "hurt" to call these as was expected by the function. This patch rewrites some of the entrypoints to split them into a "backing function" that can return an error (being slightly more iodiomatic Go) and an wrapper function to act as entrypoint (which can handle the error and exit the executable). To some extend, I'm wondering if we should change the signatures of the entrypoints to return an error so that `reexec.Init()` can handle (or return) the errors, so that logging can be handled more consistently (currently, some some use logrus, some just print); this would also keep logging out of some packages, as well as allows us to provide more metadata about the error (which reexec produced the error for example). A quick search showed that there's some external consumers of pkg/reexec, so I kept this for a future discussion / exercise. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-04-20 15:34:56 +00:00
if err := setKey(); err != nil {
_, _ = fmt.Fprintln(os.Stderr, err)
os.Exit(1)
libnetwork: processSetKeyReexec() remove defer() Split the function into a "backing" function that returns an error, and the re-exec entrypoint, which handles the error to provide a more idiomatic approach. This was part of a larger change accross multiple re-exec functions (now removed). For history's sake; here's the description for that; The `reexec.Register()` function accepts reexec entrypoints, which are a `func()` without return (matching a binary's `main()` function). As these functions cannot return an error, it's the entrypoint's responsibility to handle any error, and to indicate failures through `os.Exit()`. I noticed that some of these entrypoint functions had `defer()` statements, but called `os.Exit()` either explicitly or implicitly (e.g. through `logrus.Fatal()`). defer statements are not executed if `os.Exit()` is called, which rendered these statements useless. While I doubt these were problematic (I expect files to be closed when the process exists, and `runtime.LockOSThread()` to not have side-effects after exit), it also didn't seem to "hurt" to call these as was expected by the function. This patch rewrites some of the entrypoints to split them into a "backing function" that can return an error (being slightly more iodiomatic Go) and an wrapper function to act as entrypoint (which can handle the error and exit the executable). To some extend, I'm wondering if we should change the signatures of the entrypoints to return an error so that `reexec.Init()` can handle (or return) the errors, so that logging can be handled more consistently (currently, some some use logrus, some just print); this would also keep logging out of some packages, as well as allows us to provide more metadata about the error (which reexec produced the error for example). A quick search showed that there's some external consumers of pkg/reexec, so I kept this for a future discussion / exercise. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-04-20 15:34:56 +00:00
}
}
libnetwork: processSetKeyReexec() remove defer() Split the function into a "backing" function that returns an error, and the re-exec entrypoint, which handles the error to provide a more idiomatic approach. This was part of a larger change accross multiple re-exec functions (now removed). For history's sake; here's the description for that; The `reexec.Register()` function accepts reexec entrypoints, which are a `func()` without return (matching a binary's `main()` function). As these functions cannot return an error, it's the entrypoint's responsibility to handle any error, and to indicate failures through `os.Exit()`. I noticed that some of these entrypoint functions had `defer()` statements, but called `os.Exit()` either explicitly or implicitly (e.g. through `logrus.Fatal()`). defer statements are not executed if `os.Exit()` is called, which rendered these statements useless. While I doubt these were problematic (I expect files to be closed when the process exists, and `runtime.LockOSThread()` to not have side-effects after exit), it also didn't seem to "hurt" to call these as was expected by the function. This patch rewrites some of the entrypoints to split them into a "backing function" that can return an error (being slightly more iodiomatic Go) and an wrapper function to act as entrypoint (which can handle the error and exit the executable). To some extend, I'm wondering if we should change the signatures of the entrypoints to return an error so that `reexec.Init()` can handle (or return) the errors, so that logging can be handled more consistently (currently, some some use logrus, some just print); this would also keep logging out of some packages, as well as allows us to provide more metadata about the error (which reexec produced the error for example). A quick search showed that there's some external consumers of pkg/reexec, so I kept this for a future discussion / exercise. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-04-20 15:34:56 +00:00
func setKey() error {
execRoot := flag.String("exec-root", defaultExecRoot, "docker exec root")
flag.Parse()
// expecting 3 os.Args {[0]="libnetwork-setkey", [1]=<container-id>, [2]=<short-controller-id> }
// (i.e. expecting 2 flag.Args())
args := flag.Args()
if len(args) < 2 {
libnetwork: processSetKeyReexec() remove defer() Split the function into a "backing" function that returns an error, and the re-exec entrypoint, which handles the error to provide a more idiomatic approach. This was part of a larger change accross multiple re-exec functions (now removed). For history's sake; here's the description for that; The `reexec.Register()` function accepts reexec entrypoints, which are a `func()` without return (matching a binary's `main()` function). As these functions cannot return an error, it's the entrypoint's responsibility to handle any error, and to indicate failures through `os.Exit()`. I noticed that some of these entrypoint functions had `defer()` statements, but called `os.Exit()` either explicitly or implicitly (e.g. through `logrus.Fatal()`). defer statements are not executed if `os.Exit()` is called, which rendered these statements useless. While I doubt these were problematic (I expect files to be closed when the process exists, and `runtime.LockOSThread()` to not have side-effects after exit), it also didn't seem to "hurt" to call these as was expected by the function. This patch rewrites some of the entrypoints to split them into a "backing function" that can return an error (being slightly more iodiomatic Go) and an wrapper function to act as entrypoint (which can handle the error and exit the executable). To some extend, I'm wondering if we should change the signatures of the entrypoints to return an error so that `reexec.Init()` can handle (or return) the errors, so that logging can be handled more consistently (currently, some some use logrus, some just print); this would also keep logging out of some packages, as well as allows us to provide more metadata about the error (which reexec produced the error for example). A quick search showed that there's some external consumers of pkg/reexec, so I kept this for a future discussion / exercise. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-04-20 15:34:56 +00:00
return fmt.Errorf("re-exec expects 2 args (after parsing flags), received : %d", len(args))
}
containerID, shortCtlrID := args[0], args[1]
// We expect specs.State as a json string in <stdin>
var state specs.State
if err := json.NewDecoder(os.Stdin).Decode(&state); err != nil {
libnetwork: processSetKeyReexec() remove defer() Split the function into a "backing" function that returns an error, and the re-exec entrypoint, which handles the error to provide a more idiomatic approach. This was part of a larger change accross multiple re-exec functions (now removed). For history's sake; here's the description for that; The `reexec.Register()` function accepts reexec entrypoints, which are a `func()` without return (matching a binary's `main()` function). As these functions cannot return an error, it's the entrypoint's responsibility to handle any error, and to indicate failures through `os.Exit()`. I noticed that some of these entrypoint functions had `defer()` statements, but called `os.Exit()` either explicitly or implicitly (e.g. through `logrus.Fatal()`). defer statements are not executed if `os.Exit()` is called, which rendered these statements useless. While I doubt these were problematic (I expect files to be closed when the process exists, and `runtime.LockOSThread()` to not have side-effects after exit), it also didn't seem to "hurt" to call these as was expected by the function. This patch rewrites some of the entrypoints to split them into a "backing function" that can return an error (being slightly more iodiomatic Go) and an wrapper function to act as entrypoint (which can handle the error and exit the executable). To some extend, I'm wondering if we should change the signatures of the entrypoints to return an error so that `reexec.Init()` can handle (or return) the errors, so that logging can be handled more consistently (currently, some some use logrus, some just print); this would also keep logging out of some packages, as well as allows us to provide more metadata about the error (which reexec produced the error for example). A quick search showed that there's some external consumers of pkg/reexec, so I kept this for a future discussion / exercise. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-04-20 15:34:56 +00:00
return err
}
libnetwork: processSetKeyReexec() remove defer() Split the function into a "backing" function that returns an error, and the re-exec entrypoint, which handles the error to provide a more idiomatic approach. This was part of a larger change accross multiple re-exec functions (now removed). For history's sake; here's the description for that; The `reexec.Register()` function accepts reexec entrypoints, which are a `func()` without return (matching a binary's `main()` function). As these functions cannot return an error, it's the entrypoint's responsibility to handle any error, and to indicate failures through `os.Exit()`. I noticed that some of these entrypoint functions had `defer()` statements, but called `os.Exit()` either explicitly or implicitly (e.g. through `logrus.Fatal()`). defer statements are not executed if `os.Exit()` is called, which rendered these statements useless. While I doubt these were problematic (I expect files to be closed when the process exists, and `runtime.LockOSThread()` to not have side-effects after exit), it also didn't seem to "hurt" to call these as was expected by the function. This patch rewrites some of the entrypoints to split them into a "backing function" that can return an error (being slightly more iodiomatic Go) and an wrapper function to act as entrypoint (which can handle the error and exit the executable). To some extend, I'm wondering if we should change the signatures of the entrypoints to return an error so that `reexec.Init()` can handle (or return) the errors, so that logging can be handled more consistently (currently, some some use logrus, some just print); this would also keep logging out of some packages, as well as allows us to provide more metadata about the error (which reexec produced the error for example). A quick search showed that there's some external consumers of pkg/reexec, so I kept this for a future discussion / exercise. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-04-20 15:34:56 +00:00
return SetExternalKey(shortCtlrID, containerID, fmt.Sprintf("/proc/%d/ns/net", state.Pid), *execRoot)
}
// SetExternalKey provides a convenient way to set an External key to a sandbox
func SetExternalKey(shortCtlrID string, containerID string, key string, execRoot string) error {
uds := filepath.Join(execRoot, execSubdir, shortCtlrID+".sock")
c, err := net.Dial("unix", uds)
if err != nil {
return err
}
defer c.Close()
err = json.NewEncoder(c).Encode(setKeyData{
ContainerID: containerID,
Key: key,
})
if err != nil {
return fmt.Errorf("sendKey failed with : %v", err)
}
return processReturn(c)
}
func processReturn(r io.Reader) error {
buf := make([]byte, 1024)
n, err := r.Read(buf[:])
if err != nil {
return fmt.Errorf("failed to read buf in processReturn : %v", err)
}
if string(buf[0:n]) != success {
return fmt.Errorf(string(buf[0:n]))
}
return nil
}
func (c *Controller) startExternalKeyListener() error {
execRoot := defaultExecRoot
if v := c.Config().ExecRoot; v != "" {
execRoot = v
}
udsBase := filepath.Join(execRoot, execSubdir)
if err := os.MkdirAll(udsBase, 0o600); err != nil {
return err
}
shortCtlrID := stringid.TruncateID(c.id)
uds := filepath.Join(udsBase, shortCtlrID+".sock")
l, err := net.Listen("unix", uds)
if err != nil {
return err
}
if err := os.Chmod(uds, 0o600); err != nil {
l.Close()
return err
}
c.mu.Lock()
c.extKeyListener = l
c.mu.Unlock()
go c.acceptClientConnections(uds, l)
return nil
}
func (c *Controller) acceptClientConnections(sock string, l net.Listener) {
for {
conn, err := l.Accept()
if err != nil {
if _, err1 := os.Stat(sock); os.IsNotExist(err1) {
log.G(context.TODO()).Debugf("Unix socket %s doesn't exist. cannot accept client connections", sock)
return
}
log.G(context.TODO()).Errorf("Error accepting connection %v", err)
continue
}
go func() {
defer conn.Close()
err := c.processExternalKey(conn)
ret := success
if err != nil {
ret = err.Error()
}
_, err = conn.Write([]byte(ret))
if err != nil {
log.G(context.TODO()).Errorf("Error returning to the client %v", err)
}
}()
}
}
func (c *Controller) processExternalKey(conn net.Conn) error {
buf := make([]byte, 1280)
nr, err := conn.Read(buf)
if err != nil {
return err
}
var s setKeyData
if err = json.Unmarshal(buf[0:nr], &s); err != nil {
return err
}
var sandbox *Sandbox
search := SandboxContainerWalker(&sandbox, s.ContainerID)
c.WalkSandboxes(search)
if sandbox == nil {
return types.BadRequestErrorf("no sandbox present for %s", s.ContainerID)
}
return sandbox.SetKey(s.Key)
}
func (c *Controller) stopExternalKeyListener() {
c.extKeyListener.Close()
}