Info

struct nsproxy {

atomic_t count; struct uts_namespace *uts_ns; struct ipc_namespace *ipc_ns; struct mnt_namespace *mnt_ns; struct pid_namespace *pid_ns; struct user_namespace *user_ns; struct net *net_ns;

Currently the following areas of the kernel are aware of namespaces:

□ The UTS namespace contains the name of the running kernel, and its version, the underlying architecture type, and so on. UTS is a shorthand for Unix Timesharing System.

□ All information related to inter-process communication (IPC) is stored in struct ipc_namespace.

□ The view on the mounted filesystem is given in struct mnt_namespace.

□ struct pid_namespace provides information about process identifiers.

□ struct user_namespace is required to hold per-user information that allows for limiting resource usage for individual users.

□ struct net_ns contains all networking-related namespace parameters. There is, however, still quite a lot of effort required to make this area fully aware of namespaces as you will see in Chapter 12.

I introduce the contents of the individual namespace containers when I discuss the respective subsystem. In this chapter, we will be concerned about UTS and user namespaces. Since fork can be instructed to open a new namespace when a new task is created, appropriate flags to control the behavior must be provided. One flag is available for each individual namespace:

<sched.h>

#define

CLONE_

NEWUTS

0x04000000

/*

New

utsname group? */

#define

CLONE_

NEWIPC

0x0B000000

/*

New

ipcs */

#define

CLONE_

NEWUSER

0x10000000

/*

New

user namespace */

#define

CLONE_

NEWPID

0x20000000

/*

New

pid namespace */

#define

CLONE_

NEWNET

0x40000000

/*

New

network namespace

Each task is associated with his own view of the namespaces: <sched.h>

struct task_struct {

struct nsproxy *nsproxy;

Because a pointer is used, a collection of sub-namespaces can be shared among multiple processes. This way, changes in a given namespace will be visible in all processes that belong to this namespace.

Notice that support for namespaces must be enabled at compile time on a per-namespace basis. Generic support for namespaces is, however, always compiled in. This allows the kernel to avoid using different code for systems with and without namespaces. By providing a default namespace that is associated with every process unless specified differently, the namespace-aware code can always be used, but the results will be identical to a situation in which all properties are global and not wrapped up in namespaces if no active support for namespaces is compiled in.

The initial global namespace is defined by init_nsproxy, which keeps pointers to the initial objects of the per-subsystem namespaces:

Continue reading here: Info

Was this article helpful?

0 0