When entering a user namespace you drop privileges.
The best way I can explain it is to describe an April Fool's day joke that you can play on your friendly local sysadmin.
Create a binary and call it something like $HOME/bin/su. Have that binary
call unshare(CLONE_NEWUSER) and write to /proc/[pid]/uid_map and /proc/[pid]/gid_map so that 0 in the current user namespace maps to the current uid and gid. Have this binary exec $SHELL. No privileges required.
Report that su is working without requiring root privileges in your account.
You can look around in /proc/self/status and see that your uid and gid are 0 and that you have all privs.
Extra points if you can get your local sysadmin to start trying to do things and from your $HOME/bin/su, because things really won't work and if you don't realize what is going on you are likely to be quite frustrated.
Services won't restart. You can't kill processes owned by other users etc.
Having a pam module set it up so that the user that looks like root has a distinct uid from everyone else is trickier to setup but could be more entertaining.
So while you have CAP_NET_BIND and can bind to any port in any network namespace you create, creating a network namespace won't do you much good because that network namespace is not connected to any other network namespace.
Posted Jan 4, 2013 2:00 UTC (Fri) by kevinm (guest, #69913)
[Link]
Thanks Eric.
So from this it sounds like all the other types of namespaces (net, pid, mount...) are "owned" by a user namespace (the one in which they were created). When a permission check is done, it is done using the user namespace that owns that namespace that the relevant resource is in - for example, when I try to bind a privileged port, the permission check is done using the user namespace that owns the current network namespace (not the user namespace of the current process, which might well be different). Does that sound like the right concept?