lxc-usernsexec(1)

πŸ’… lxc-usernsexec β€” the lxc-usernsexec(1) manual, but make it make sense

okay bestie so picture this: you're in lxc-usernsexec(1) land, and the whole point is running a task as root inside a brand-new user namespace. that's it, that's the vibe. it's giving "i want the power of root but like... in my own little bubble" ✨


🌸 NAME 🌸

lxc-usernsexec β€” run a task as root in a new user namespace. no cap, that's literally her whole job 🫢


πŸŽ€ SYNOPSIS πŸŽ€

lxc-usernsexec [-m uid-map] {-- command}

like, you can pass -m uid-map, you can pass -- command, and honestly both are optional depending on what era of your life you're in πŸ’…


✨ DESCRIPTION ✨

so lxc-usernsexec can be used to run a task as root in a new user namespace. iconic behavior honestly. that's the description, she's short and sweet and knows exactly what she is πŸ¦‹


πŸ”₯ OPTIONS πŸ”₯

  • -m uid-map β€” this is the uid map you're gonna use inside the user namespace. each map is made of four colon-separated values, and yes you read that right, four, count them:
    • first up, a single character: u, g, or b β€” this tells you whether the map is about user ids, group ids, or both, respectively
    • next: the first userid in the user namespace
    • next: the first userid as seen on the host
    • finally: how many ids are being mapped

you can specify more than one map, and honestly? you probably will. if you specify no map at all, the default is that the full uid and gid ranges granted by /etc/subuid and /etc/subgid get mapped to the uids and gids starting at 0 in the container. cute, convenient, love that for you πŸ’–

⚠️ okay this part matters: lxc-usernsexec always tries to setuid and setgid to 0 in the namespace. so uid 0 in the namespace must be mapped. like, non-negotiable bestie, it's not gonna work otherwise 😭

🌈 EXAMPLES 🌈

want a shell with the full allotted subuids mapped into the container? say less:

lxc-usernsexec

want a different shell than /bin/sh? valid, /bin/sh isn't everybody's main character:

lxc-usernsexec -- /bin/bash

okay now the juicy one πŸ‘‘ β€” say your user id is 1000, root in a container is mapped to 190000, and you wanna chown a file you own to root in the container. here's the move:

lxc-usernsexec -m b:0:1000:1 -m b:1:190000:1 -- /bin/chown 1:1 $file

so what's happening here: this maps your userid to root in the user namespace, and maps 190000 to uid 1. and because root in the user namespace is privileged over all the userids mapped into that namespace, you're allowed to change the file ownership β€” which, btw, you could not do on the host with a plain simple chown. slay, loophole queen πŸ’…βœ¨


πŸ¦‹ SEE ALSO πŸ¦‹

the whole friend group, no one left out: lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-unfreeze(1), lxc-attach(1), lxc.conf(5)


and that's the page!! πŸŽ€ this edition of lxc-usernsexec(1) is dated 2026-05-01 and comes straight from the lxc-usernsexec source/version, so you know it's the real one. go forth and namespace responsibly bestie πŸ«ΆπŸ’œ

πŸ“¦ where this page comes from