I'll try and answer both this and your earlier question as they are related.
The doors to namespaces are files in /proc/*/ns/* and /proc/*/task/*/ns/*.
A namespace is created by a process unsharing its namespace. A namespace can then be made permanent by bind-mounting the ns file to some other place.
That's what ip netns does for instance for net ...
It means the process has a separate copy of the hostname and the (now mostly unused) NIS domain name, so it can set it to something else without affecting the rest of the system.
The hostname is set via sethostname and is the nodename member of the struct returned by uname. The NIS domain name is set by setdomainname and is the domainname member of the ...
Running unshare -m gives the calling process a private copy of its mount namespace, and also unshares file system attributes so that it no longer shares its root directory, current directory, or umask attributes with any other process.
So what does the above paragraph say? Let us try and understand using a simple example.
I do the below ...
In a nutshell, namespaces provide a way to build a virtual Linux system inside a larger Linux system. This is different from running a virtual machine that runs as an unprivileged process: the virtual machine appears as a single process in the host, whereas processes running inside a namespace are still running on the host system.
A virtual system running ...
Create a PID namespace
The correct command to use here is unshare. Note that the necessary options to do this are only available from util-linux 2.23. The idea is to create a new PID namespace for the program you are running such that all its children are also created in this namespace. You can run a command in a new PID namespace simply by doing:
If you have util-linux v2.28 or above you can use lsns:
NS TYPE NPROCS PID USER COMMAND
4026531836 pid 78 1 root /sbin/init
4026531837 user 79 1 root /sbin/init
4026531838 uts 78 1 root /sbin/init
4026531839 ipc 78 1 root /sbin/init
The difference is that / has child mounts. Inside a user namespace, you are not allowed to separate inherited mounts from their child mounts. A more obvious example is that you are not allowed to umount /proc. Otherwise, it could suddenly grant you access to files that were hidden underneath other mounts. Overmounts are sometimes used deliberately as a ...
Utilities for working with namespaces have improved since this question was asked in 2013.
lsns from the util-linux package can list all of the different types of namespaces, in various useful formats.
# lsns --help
lsns [options] [<namespace>]
List system namespaces.
-J, --json use JSON output format
-l, --list ...
The answer is: In Unix-like systems, file names are composed of bytes, not characters. At least from the perspective of the kernel and its APIs.
A Unix-like kernel is normally neutral about any byte value but \000 (ASCII: NUL) and \057 (ASCII: slash). In Linux, there are no other restrictions at the filesystem layer, but certain FS drivers and certain their ...
Entering a mount namespace before setting up a chroot, lets you avoid cluttering the host namespace with additional mounts, e.g. for /proc. You can use chroot inside a mount namespace as a nice and simple hack.
I think there are advantages to understanding pivot_root, but it has a bit of a learning curve. The documentation does not quite explain ...
If you are on a systemd based distribution with a util-linux version less than 2.27, you will see this unintuitive behaviour. This is because CLONE_NEWNS propogates flags such as shared depending on a setting in the kernel. This setting is normally private, but systemd changes this to shared. As of util-linux 2.27, a patch was made that changes the default ...
What's happening here is that your "unshare" process does not have access to write to the setgroups (and uid_maps, gid_maps) files on the external user namespace.
In that namespace, the pseudo-files in /proc/<PID> will be root-owned, and as if your effective uid is still that of your own user, you will not have access to write to those files.
You can ...
The traditional answer is to run the program as another user and use iptables -m owner. That way, the network configuration is shared. However, with the advent of namespaces, there is an easier way.
With namespaces, you unshare the network, then create a virtual network link if you need limited network access.
To share unix domain sockets, all you need is ...
Inkscape has a feature for this as of 0.47:
$ INKSCAPE_PORTABLE_PROFILE_DIR=/some/other/path inkscape --args
Put your script's custom preferences.xml file in /some/other/path. It should be a dedicated directory, because Inkscape will populate it with all the other files it normally puts in ~/.config/Inkscape when you run it like this.
ps now has output options for the different types of namespaces associated with processes: ipcns, mntns, netns, pidns, userns, and utsns. For this question, the relevant one is the PID namespace, or pidns.
so if you wanted to find out the PID namespace id for, e.g., pid 459:
# ps -h -o pidns -p 459
and to list all processes in that namespace:
Normally, chroot is about "limiting privileges", not granting users their own IF to play with...
But in any case: if you feel like doing some work, you may start your chroot environment within a new network namespace. You find an introduction here. Then the last command, the one that places you into the new network namespace, which in the guide above is
I (finally) tested it in Fedora Rawhide. It looks like my initial impression is correct: if you run seteuid(50) inside a namespace, but uid 50 inside the namespace doesn't correspond to a uid outside the namespace, then the call to seteuid simply fails.
In here, I'll use "kernel uid" to refer to a process's uid as seen by the kernel (and most processes ...
Because Inkscape is FOSS software, we can just add an option to the program which will let you pass the name of another config file, like so:
=== modified file 'src/inkscape.cpp'
--- src/inkscape.cpp 2013-09-28 19:20:27 +0000
+++ src/inkscape.cpp 2013-11-02 04:07:45 +0000
@@ -1443,6 +1443,12 @@
prefdir = g_strdup(val);
In later versions of util-linux, unshare gained the --map-root-user option. Quoting from unshare(1) version 2.26.2:
Run the program only after the current effective user and group IDs have been mapped to the superuser UID and GID in the newly created user namespace. This makes it possible to conveniently gain capabilities ...
Yes, mount namespaces is one approach:
$ cat file
$ cat other-file
$ sudo unshare -m zsh -c 'mount --bind other-file file; USERNAME=$SUDO_USER; cat file'
$ cat file
Above using zsh to restore the uid/gids of the original user for the hijacked cat command.
You have two questions in one:
what are the empty files in /var/run/netns/?
how to use /etc/netns/ which doesn't even exist?
What are the empty files in /var/run/netns/?
Some understanding of namespaces is needed. I can't explain it in detail here. Suffice to say that a namespace once created will (partition some kernel resource such as network, and) ...
Linux kernel namespace is a concept used for isolating a group of processes from others with respect to access to a system resource. For example two different PID namespaces may contain processes with identical PIDs but completely different process image. They are often used in OS-level virtualisation, in which a single kernel is simultaneously running ...
Yes. You can look at its /proc/$PID/mountinfo or else you can use the findmnt -N switch - about which findmnt --help says:
-N, --task <tid>
use alternative namespace (/proc/<tid>/mountinfo file)
findmnt also tracks the PROPAGATION flag which is a mountinfo field which reports on exactly this information - which processes share which mounts.
The issue is that you're trying to route a packet from namespace ns_snd through ns_mid to ns_rcv. The kernel is going to treat the namespaces as if they were separate hosts. Meaning you have to configure the kernel to act as a router.
This is rather simple to do:
sudo ip netns exec $NS_MID sysctl -w net.ipv4.ip_forward=1
That's the "Name Space File System", used by the setns system call and, as its source code shows, Name Space related ioctl's (e.g. NS_GET_USERNS, NS_GET_OWNER_UID...)
NSFS pseudo-files entries used to be provided by the /proc file system until Linux 3.19. Here is the commit of this change.
See Stephen Kitt's comment about a possible explanation about this ...
Yes. If your kernel supports user_namespaces (and they are enabled), you can first "simulate the root" user, which then gets the right to invoke chroot (as a real root user). (Which previously needed to be restricted only to the root user because of a possibility for privilege escalation by a normal user (say, through set-UID-root binaries and custom ...
Several things are mixed up:
In your graphic you let the “default namespace” look like a switch, but you configured it to a router.
With a router in the middle, vlan1 and the other vlan1 are different. They don’t share the same LAN, so they can’t be in the same VLAN.
Your vconfig calls will not find veth11 or veth13, because they are not in the default ...
You can not start a process as the child of the shell, and then "reparent" it so another process becomes it's parent.
So you need to use a parent process that explicitly starts the children.
init with PID 1 is an exception, processes can become it's child as it collects processes that lost their original parent process.
(With upstart, there can be ...
This is a security feature, described in the PID namespace man page.
While processes may freely descend into child PID namespaces (e.g.,
using setns(2) with CLONE_NEWPID), they may not move in the other
direction. That is to say, processes may not enter any ancestor
namespaces (parent, grandparent, etc.). Changing PID ...