Curious;

• should we also consider adding some of these (rootless-specific) checks to contrib/check-config.sh? (if apparmor is available, also check for the apparmor_restrict_unprivileged_userns feature?
• Somewhat orthogonal; I notice the only place we use the rootlesskit vendoring is to include information to docker info, but we also (have to) do a bunch of local work to collect additional information;

  moby/daemon/info_unix.go

  Lines 264 to 313 in 460b4ae

  	switch rlInfo.NetworkDriver.Driver {
  	case "slirp4netns":
  	err = func() error {
  	rv, err := exec.CommandContext(ctx, "slirp4netns", "--version").Output()
  	if err != nil {
  	if errdefs.IsContext(err) {
  	return err
  	}
  	log.G(ctx).WithError(err).Warn("Failed to retrieve slirp4netns version")
  	return nil
  	}
  	_, ver, commit, err := parseRuntimeVersion(string(rv))
  	if err != nil {
  	log.G(ctx).WithError(err).Warn("Failed to parse slirp4netns version")
  	return nil
  	}
  	v.Components = append(v.Components, types.ComponentVersion{
  	Name: "slirp4netns",
  	Version: ver,
  	Details: map[string]string{
  	"GitCommit": commit,
  	},
  	})
  	return nil
  	}()
  	if err != nil {
  	return err
  	}
  	case "vpnkit":
  	err = func() error {
  	out, err := exec.CommandContext(ctx, "vpnkit", "--version").Output()
  	if err != nil {
  	if errdefs.IsContext(err) {
  	return err
  	}
  	log.G(ctx).WithError(err).Warn("Failed to retrieve vpnkit version")
  	return nil
  	}
  	v.Components = append(v.Components, types.ComponentVersion{
  	Name: "vpnkit",
  	Version: strings.TrimSpace(strings.TrimSpace(string(out))),
  	})
  	return nil
  	}()
  	if err != nil {
  	return err
  	}
  	}
  	return nil

  wondering if those are parts that should eventually be handled by rootlesskit (and returned by the Info it returns) 🤔

☝️ TBH; still a bit looking at the best direction to take there; the rootlesskit case is a bit "weird" because it's rootlesskit running the engine, and the engine itself doesn't "call" rootlesskit here. Still somewhat wondering what it would take to integrate the rootlesskit functionality in the daemon itself.

cc @vvoland (for back porting); I THINK we only need the last two commits (vendoring changes are effectively a "no-op" from a rootlesskit perspective.

should we also consider adding some of these (rootless-specific) checks to contrib/check-config.sh? (if apparmor is available, also check for the apparmor_restrict_unprivileged_userns feature?

Ideally yes, but it could be complicated

Somewhat orthogonal; I notice the only place we use the rootlesskit vendoring is to include information to docker info, but we also (have to) do a bunch of local work to collect additional information;

Yes 👍, eventually

Still somewhat wondering what it would take to integrate the rootlesskit functionality in the daemon itself.

We may consider this, but it may rather result in more complicated code base

I THINK we only need the last two commits (vendoring changes are effectively a "no-op" from a rootlesskit perspective.

Yes

Opened a v25 backport.
Also wanted to open backports for v23/v24, but they're still on rootlesskit v1.:

Three's a pending one for v23.0, but it's "on hold";

• [23.0] Vendor rootlesskit v2 #47258