Namespace contrained helper execution

The call_usermodehelper() function executes all binaries in the global "init" root context. This doesn't allow a binary to be run within the callers namespace (aka. a container).

Both containerized NFS client and NFS server need the ability to execute a binary within their container. To do this create a new nsproxy within the callers' context so it can be used for setup prior to calling do_execve() from the user mode helper thread runner.

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 54 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

Quoted 3 lines

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

Quoted 12 lines

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

Ian

Quoted 60 lines · Eric W. Biederman

Quoted 57 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

Review

Quoted 6 lines

(quoted diff) +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 3 lines

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

Your recommending I have a look at the core dump helper, that's fine, I'll do that.

Quoted 20 lines

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

Quoted 61 lines · Ian Kent

Quoted 60 lines · Eric W. Biederman

Quoted 57 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

Review

Quoted 6 lines

(quoted diff) +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 6 lines

Quoted 3 lines

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

Your recommending I have a look at the core dump helper, that's fine, I'll do that.

I am just describing it because it came up. Core dumps are a much easier case than nfs.

Frankly if we can figure out how to run the user mode helpers from the kernel with an appropriate context and not involve userspace I think that will be better for everyone, as it involves fewer moving parts at the end of the day.

Quoted 20 lines

Quoted 20 lines

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 8 lines

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

No it is not. That is precisely why we have call_usermodehelper instead of just forking and exec'ing something. The context which triggers the call can be completely different from where you want to run.

Quoted 6 lines

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

That is part of it.

However in the context of nfs the correct context is determined at mount time, and so when call_usermodehelper() is invoked the only link to that correct context that we have is the nfs super block.

In a pathological case a userspace application can create a new user namespace, and a new mount namespace and completely rearrange the mounts, and deliberately trigger an nfs user mode helper. If we were to use that applications context it could control which userspace application the kernel invoked.

So deeply and fundamentally for the case of nfs you need to capture the context at nfs mount time. The easiest way would be to fork a kernel thread when nfs is mounted, that captures the entire context.

We might be able to do something a little more sophisticated and a little less resource intensive, like pick on the init process that exists when nfs is mounted.

Those are the general parameters.

Eric

n Tue, 25 Nov 2014, Eric W. Biederman wrote:
Hi,

Quoted 124 lines

Quoted 61 lines · Ian Kent

Quoted 60 lines · Eric W. Biederman

Quoted 57 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

Review

Quoted 6 lines

(quoted diff) +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 6 lines

Quoted 3 lines

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

Your recommending I have a look at the core dump helper, that's fine, I'll do that.

I am just describing it because it came up. Core dumps are a much easier case than nfs.

Frankly if we can figure out how to run the user mode helpers from the kernel with an appropriate context and not involve userspace I think that will be better for everyone, as it involves fewer moving parts at the end of the day.

Quoted 20 lines

Quoted 20 lines

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 8 lines

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

No it is not. That is precisely why we have call_usermodehelper instead of just forking and exec'ing something. The context which triggers the call can be completely different from where you want to run.

Quoted 6 lines

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

That is part of it.

However in the context of nfs the correct context is determined at mount time, and so when call_usermodehelper() is invoked the only link to that correct context that we have is the nfs super block.

Quoted 5 lines

In a pathological case a userspace application can create a new user namespace, and a new mount namespace and completely rearrange the mounts, and deliberately trigger an nfs user mode helper. If we were to use that applications context it could control which userspace application the kernel invoked.

Then it seems it would never be safe to try to execve /sbin/request-key within the calling process' mnt_ns, so if we want to do some work within that namespace the transition to it needs to happen after the upcall, after /sbin/request-key calls the appropriate helper.

And instead of transitioning into this context before execve, instead pass it along to allow the userspace helper to do setns()..

Quoted 6 lines

So deeply and fundamentally for the case of nfs you need to capture the context at nfs mount time. The easiest way would be to fork a kernel thread when nfs is mounted, that captures the entire context.

Quoted 3 lines

We might be able to do something a little more sophisticated and a little less resource intensive, like pick on the init process that exists when nfs is mounted.

The only namespace that needs to be preserved from mount time would be the mount namespace which can be pulled from the mount itself and passed along in the key request.

Or if we tracked the mount namespace when creating a user namespace, we could climb out of the mount namespaces created within user namespaces by following them out. Does that sound sane, or completely nuts?

Quoted 1 line

Those are the general parameters.

It does seem very expensive to keep a thread around for every mount; I'm still trying to find a way around it..

Quoted 133 lines · Benjamin Coddington

n Tue, 25 Nov 2014, Eric W. Biederman wrote:
Hi,

Quoted 129 lines

Quoted 61 lines · Ian Kent

Quoted 60 lines · Eric W. Biederman

Quoted 57 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

Review

Quoted 6 lines

(quoted diff) +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 6 lines

Quoted 3 lines

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

Your recommending I have a look at the core dump helper, that's fine, I'll do that.

I am just describing it because it came up. Core dumps are a much easier case than nfs.

Frankly if we can figure out how to run the user mode helpers from the kernel with an appropriate context and not involve userspace I think that will be better for everyone, as it involves fewer moving parts at the end of the day.

Quoted 20 lines

Quoted 20 lines

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 8 lines

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

No it is not. That is precisely why we have call_usermodehelper instead of just forking and exec'ing something. The context which triggers the call can be completely different from where you want to run.

Quoted 6 lines

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

That is part of it.

However in the context of nfs the correct context is determined at mount time, and so when call_usermodehelper() is invoked the only link to that correct context that we have is the nfs super block.

In a pathological case a userspace application can create a new user namespace, and a new mount namespace and completely rearrange the mounts, and deliberately trigger an nfs user mode helper. If we were to use that applications context it could control which userspace application the kernel invoked.

Quoted 4 lines

Then it seems it would never be safe to try to execve /sbin/request-key within the calling process' mnt_ns, so if we want to do some work within that namespace the transition to it needs to happen after the upcall, after /sbin/request-key calls the appropriate helper.

Quoted 2 lines

And instead of transitioning into this context before execve, instead pass it along to allow the userspace helper to do setns()..

I still don't see the difference between, given an appropriate pid, using the open()/setns() mechanism in kernel similar to nsenter(1).

In that case the setup is done before the first exec rather than between the first and second exec (the one in nsenter). Our other approach essentially did that but (incorrectly) used the current process pid and didn't deal with all the namespace types as nsenter does.

Isn't the real problem getting hold of an appropriate pid to use for the open/setns that belongs to a process that's still running? What else is needed, Eric?

Not having looked at how core dumping works before, I'm having difficulty working out what gets executed in user space so I can't be sure that what I'm saying is accurate, can someone spell this out for me please?

Quoted 11 lines

Quoted 7 lines

So deeply and fundamentally for the case of nfs you need to capture the context at nfs mount time. The easiest way would be to fork a kernel thread when nfs is mounted, that captures the entire context.

We might be able to do something a little more sophisticated and a little less resource intensive, like pick on the init process that exists when nfs is mounted.

The only namespace that needs to be preserved from mount time would be the mount namespace which can be pulled from the mount itself and passed along in the key request.

Sounds simple but isn't it the case we don't know and shouldn't have to care about what system calls the helper uses since the environment should "see" what it's supposed to?

Quoted 4 lines

Or if we tracked the mount namespace when creating a user namespace, we could climb out of the mount namespaces created within user namespaces by following them out. Does that sound sane, or completely nuts?

Quoted 4 lines

Quoted 1 line

Those are the general parameters.

It does seem very expensive to keep a thread around for every mount; I'm still trying to find a way around it..

Yeah, that's not such a good idea.

Several hundred mounts is going to create a big mess for system administrators, not to mention the overhead. It's right up there with symlinking /etc/mtab to /proc/self/mounts at sites with large direct mount maps.

Quoted 134 lines · Ian Kent

Quoted 133 lines · Benjamin Coddington

n Tue, 25 Nov 2014, Eric W. Biederman wrote:
Hi,

Quoted 129 lines

Quoted 61 lines · Ian Kent

Quoted 60 lines · Eric W. Biederman

Quoted 57 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

Review

Quoted 6 lines

(quoted diff) +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 6 lines

Quoted 3 lines

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

Your recommending I have a look at the core dump helper, that's fine, I'll do that.

I am just describing it because it came up. Core dumps are a much easier case than nfs.

Frankly if we can figure out how to run the user mode helpers from the kernel with an appropriate context and not involve userspace I think that will be better for everyone, as it involves fewer moving parts at the end of the day.

Quoted 20 lines

Quoted 20 lines

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 8 lines

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

No it is not. That is precisely why we have call_usermodehelper instead of just forking and exec'ing something. The context which triggers the call can be completely different from where you want to run.

Quoted 6 lines

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

That is part of it.

However in the context of nfs the correct context is determined at mount time, and so when call_usermodehelper() is invoked the only link to that correct context that we have is the nfs super block.

In a pathological case a userspace application can create a new user namespace, and a new mount namespace and completely rearrange the mounts, and deliberately trigger an nfs user mode helper. If we were to use that applications context it could control which userspace application the kernel invoked.

Quoted 4 lines

Quoted 4 lines

Then it seems it would never be safe to try to execve /sbin/request-key within the calling process' mnt_ns, so if we want to do some work within that namespace the transition to it needs to happen after the upcall, after /sbin/request-key calls the appropriate helper.

No. We never want to do work in the calling process's mnt_ns. We want to work in the mounters mnt_ns which given mount propagation can be something completely and totally different.

Quoted 6 lines

Quoted 2 lines

And instead of transitioning into this context before execve, instead pass it along to allow the userspace helper to do setns()..

I still don't see the difference between, given an appropriate pid, using the open()/setns() mechanism in kernel similar to nsenter(1).

Quoted 8 lines

In that case the setup is done before the first exec rather than between the first and second exec (the one in nsenter). Our other approach essentially did that but (incorrectly) used the current process pid and didn't deal with all the namespace types as nsenter does.

Isn't the real problem getting hold of an appropriate pid to use for the open/setns that belongs to a process that's still running? What else is needed, Eric?

Essentially that is the real problem. Getting ahold of the context of the container in which a filesystem was mounted.

Now it isn't just namespaces but also cgroups and uids and gids and capabilities and process groups and sessions. There are a whole host of little things that need to be right to run a user mode helper, and in particular to run a user mode helper in a ``container''.

Quoted 4 lines

Not having looked at how core dumping works before, I'm having difficulty working out what gets executed in user space so I can't be sure that what I'm saying is accurate, can someone spell this out for me please?

In that case what happens is that the normal user mode helper process runs started by kthreadd and if %P is specified that processes knows the pid in the initial pid namespace. Which is good enough to use nsenter and otherwise figure out the appropriate container from the process that is dumping core.

It is easier with core dumping as we don't have the disconnect in contexts that we do with filesystems.

Quoted 11 lines

Quoted 11 lines

Quoted 7 lines

So deeply and fundamentally for the case of nfs you need to capture the context at nfs mount time. The easiest way would be to fork a kernel thread when nfs is mounted, that captures the entire context.

We might be able to do something a little more sophisticated and a little less resource intensive, like pick on the init process that exists when nfs is mounted.

The only namespace that needs to be preserved from mount time would be the mount namespace which can be pulled from the mount itself and passed along in the key request.

We absolutely can not pull the mount from the mount namespace. Mount propagtion makes that impossible.

Quoted 3 lines

Sounds simple but isn't it the case we don't know and shouldn't have to care about what system calls the helper uses since the environment should "see" what it's supposed to?

The tricky bit is setting the environment correctly.

Quoted 4 lines

Quoted 4 lines

Or if we tracked the mount namespace when creating a user namespace, we could climb out of the mount namespaces created within user namespaces by following them out. Does that sound sane, or completely nuts?

For what we have today (where the global root user has to mount the nfs filesystem) tracking the mount namespace at the time nfs is mounted is close to enough. However if we are going to work this out we need to solve this for an nfs where we are brave enough to set
".fs_flags = FS_USERNS_MOUNT".

The NFS code base is nearly at the point where we can reasonably talk about supporting unprivileged mounts.

Quoted 11 lines

Quoted 4 lines

Quoted 1 line

Those are the general parameters.

It does seem very expensive to keep a thread around for every mount; I'm still trying to find a way around it..

Yeah, that's not such a good idea.

Several hundred mounts is going to create a big mess for system administrators, not to mention the overhead. It's right up there with symlinking /etc/mtab to /proc/self/mounts at sites with large direct mount maps.

A thread will cost you maybe 40k. In the grand scheme of things that really isn't a lot. I agree that it would be nice to do better than
one thread per mount. But I start with a thread as a reference point
as that is the trivial way to get things correct.

To relax it from a thread per mount we need definitions that we can explain to folks in userspace about when and where user mode helpers will run.

I think something like Oleg's proposal to use the init process of a pid namespace as our reference is worth exploring. We certainly don't match the mounters exact environment when running user mode helpers today, so there is leeway for some relaxation without breaking userspace.

There are funny issues without forking a thread to run the user mode helpers, such as what happens if all of the processes in the container exit what should happen? Remember that mount propagation allows the filesystem to propagate into different mount namespaces and bind mounts allow the filesystem to show up in different places in the those mount namespaces.

If the container has exited should the filesystem remain functional? Should the kernel keep pieces of the container alive to run user mode helpers?

Eric

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

Those are the general parameters.

It does seem very expensive to keep a thread around for every mount; I'm still trying to find a way around it..

Quoted 6 lines

Yeah, that's not such a good idea.

Several hundred mounts is going to create a big mess for system administrators, not to mention the overhead. It's right up there with symlinking /etc/mtab to /proc/self/mounts at sites with large direct mount maps.

A thread will cost you maybe 40k. In the grand scheme of things that really isn't a lot. I agree that it would be nice to do better than
one thread per mount. But I start with a thread as a reference point
as that is the trivial way to get things correct.

Quoted 134 lines · Ian Kent

Quoted 133 lines · Benjamin Coddington

n Tue, 25 Nov 2014, Eric W. Biederman wrote:
Hi,

Quoted 129 lines

Quoted 61 lines · Ian Kent

Quoted 60 lines · Eric W. Biederman

Quoted 57 lines · Ian Kent

Quoted 34 lines · Eric W. Biederman

Quoted 25 lines · Oleg Nesterov

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

Review

Quoted 6 lines

(quoted diff) +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

That would certainly be a better approach, and roughly equivalent to what exists here. That would even ensure we remain in the proper cgroups, and lsm context.

Quoted 6 lines

The practical problem with the approach presented here is that I can hijack any user mode helper I wish, and make it run in any executable I wish as the global root user.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

LOL, OK, so there's a problem with this.

But, how should a user mode helper execute within a namespace (or more specifically within a container)?

Suppose a user mode helper program scans through the pid list and somehow picks the correct process pid and then does an open()/setns()/execve().

Does that then satisfy the requirements? What needs to be done to safely do that in kernel?

The other approach I've considered is doing a full open()/setns() in kernel (since the caller already knows its pid) but it sounds like that's not right either.

Quoted 6 lines

Quoted 3 lines

The approach we agreed upon with the core dump helper was to provide enough information that userspace could figure out what was the appropriate policy and call nsenter/setns.

Your recommending I have a look at the core dump helper, that's fine, I'll do that.

I am just describing it because it came up. Core dumps are a much easier case than nfs.

Frankly if we can figure out how to run the user mode helpers from the kernel with an appropriate context and not involve userspace I think that will be better for everyone, as it involves fewer moving parts at the end of the day.

Quoted 20 lines

Quoted 20 lines

The only sane approach I can think of in the context of nfs is to fork a kernel thread at mount time that has all of the appropriate context because it was captured from the privileged mounting process, and use that kernel as the equivalent of kthreadd.

There may be some intermediate ground where we capture things or we use the init process of the pid namespace (captured at mount time) as our template/reference process.

If we are going to set this stuff up in the kernel we need a reference process that we can create children of because what is possible with respect to containers keeps changing, and it is extremely error prone to figure out what all othe crazy little bits are, and to update everything every time someone tweaks the kernel's capabilities. We have kthreadd because it was too error prone to scrub a userspace thread of all of the userspace bits and make it the equivalent of what kthreadd is today.

Of course it is also rather nice to have something to hang everything else on.

Quoted 8 lines

Quoted 2 lines

In summary we need a reference struct task that is all setup properly so that we can create an appropriate kernel thread.

I'm having trouble understanding what your getting at here but I'm not that sharp so bear with me.

When call_usermodehelper() is called it's called from a process that is within the context within which the execution is required.

No it is not. That is precisely why we have call_usermodehelper instead of just forking and exec'ing something. The context which triggers the call can be completely different from where you want to run.

Quoted 6 lines

So what information do we not have available for setup?

Are you saying that the problem is that when the user mode helper run thread is invoked we don't have the information available that was present when call_usermodehelper() was called and that's where the challenge lies?

That is part of it.

However in the context of nfs the correct context is determined at mount time, and so when call_usermodehelper() is invoked the only link to that correct context that we have is the nfs super block.

In a pathological case a userspace application can create a new user namespace, and a new mount namespace and completely rearrange the mounts, and deliberately trigger an nfs user mode helper. If we were to use that applications context it could control which userspace application the kernel invoked.

Quoted 4 lines

Quoted 4 lines

Then it seems it would never be safe to try to execve /sbin/request-key within the calling process' mnt_ns, so if we want to do some work within that namespace the transition to it needs to happen after the upcall, after /sbin/request-key calls the appropriate helper.

No. We never want to do work in the calling process's mnt_ns. We want to work in the mounters mnt_ns which given mount propagation can be something completely and totally different.

Quoted 6 lines

Quoted 2 lines

And instead of transitioning into this context before execve, instead pass it along to allow the userspace helper to do setns()..

I still don't see the difference between, given an appropriate pid, using the open()/setns() mechanism in kernel similar to nsenter(1).

Quoted 8 lines

In that case the setup is done before the first exec rather than between the first and second exec (the one in nsenter). Our other approach essentially did that but (incorrectly) used the current process pid and didn't deal with all the namespace types as nsenter does.

Isn't the real problem getting hold of an appropriate pid to use for the open/setns that belongs to a process that's still running? What else is needed, Eric?

Essentially that is the real problem. Getting ahold of the context of the container in which a filesystem was mounted.

Now it isn't just namespaces but also cgroups and uids and gids and capabilities and process groups and sessions. There are a whole host of little things that need to be right to run a user mode helper, and in particular to run a user mode helper in a ``container''.

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

Quoted 2 lines · Eric W. Biederman

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

Is there any particular reason the upcalled program has to be run as root? Could the kernel not run it as something else - perhaps the caller's UID,GID or even something anonymous?

Also, call_sbin_request_key() could be given a parameter to call something other than /sbin/request-key, and key_type::request_key could be used.

Quoted 11 lines · David Howells

Quoted 2 lines · Eric W. Biederman

Ian if we were to merge this I believe you would win the award for easiest path to a root shell.

Is there any particular reason the upcalled program has to be run as root? Could the kernel not run it as something else - perhaps the caller's UID,GID or even something anonymous?

Also, call_sbin_request_key() could be given a parameter to call something other than /sbin/request-key, and key_type::request_key could be used.

Fundamentally the upcall needs to happen with enough privileges to do the job, and that means running in practice running as root in the appropriate context. If we didn't need to gain privileges we wouldn't need an upcall.

In the code I was critisizing struct cred was not being changed because of what I believe was an ignorance of what task->nsproxy was about and is for.

It is straight forward to save off a for a kernel thread from the process calling mount and make it responsible for the upcall and use that as the parent for all of the containerized upcalls, and we could easily run with that threads permissions.

We can't use the context of the triggering user but we instead need to use the context of the mounter of the filesystem. As otherwise the triggering user can control what is /sbin/request-key and cause problems that way.

Quoted 5 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Yes.

And I have another concern... this is mostly a feeling, I can be easily wrong but:

Quoted 12 lines · Ian Kent

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Quoted 4 lines

The call_usermodehelper() function executes all binaries in the global "init" root context. This doesn't allow a binary to be run within the callers namespace (aka. a container).

Please see below.

Quoted 5 lines

Both containerized NFS client and NFS server need the ability to execute a binary within their container. To do this create a new nsproxy within the callers' context so it can be used for setup prior to calling do_execve() from the user mode helper thread runner.

and probably we also need this for coredump helpers, we want them to be per-namespace.

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 652

Quoted 1 line

kernel/kmod.c +1 -0

+	switch_task_namespaces(current, ns);

This doesn't look sane because this won't switch task_active_pid_ns().

And this reminds me another discussion, please look at
http://marc.info/?l=linux-kernel&m=138479570926192

Once again, this is just an idea to provoke more discussion. I am starting to think that perhaps we need pid_ns->umh_helper (init by default). And PR_SET_NS_UMH_HELPER.

Quoted 4 lines · Oleg Nesterov

Let me first apologize, I didn't actually read this series yet.

But I have to admit that so far I do not like this approach... probably I am biased.

Oleg, thanks for your comments.

Quoted 9 lines · Ian Kent

Quoted 4 lines

The call_usermodehelper() function executes all binaries in the global "init" root context. This doesn't allow a binary to be run within the callers namespace (aka. a container).

Please see below.

Quoted 8 lines

Quoted 5 lines

Both containerized NFS client and NFS server need the ability to execute a binary within their container. To do this create a new nsproxy within the callers' context so it can be used for setup prior to calling do_execve() from the user mode helper thread runner.

and probably we also need this for coredump helpers, we want them to be per-namespace.

To save me some time could you point me to some of the related code please. I don't normally play in that area.

Quoted 13 lines

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 651

Quoted 6 lines

kernel/kmod.c +5 -0

+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	struct nsproxy *ns = info->data;
+
+	mntns_setfs(ns->mnt_ns);

Firstly, it is not clear to me if we should use the caller's ->mnt_ns. Let me remind about the coredump. The dumping task can cloned with CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand this enough.

Quoted 3 lines

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 652

Quoted 1 line

kernel/kmod.c +1 -0

+	switch_task_namespaces(current, ns);

This doesn't look sane because this won't switch task_active_pid_ns().

I wondered about that too but I didn't design the open()/setns() interface and TBH I've been wondering how he hell it is supposed to work because of exactly this.

The statement amounts to saying that the
fd = open(/proc/<pid in target namespace>/ns/mnt); setns(fd);
won't set the namespace properly but the documentation I've seen so far (there's probably more that I need to see, I'll look further) implies this is sufficient.

How does one correctly set the namespace in user space since each of the /proc/<pid>/ns/<namespace> will use a slightly different proc_ns_operations install function?

Are we saying that, for example, if open(/proc/<pid>/ns/pid)/setns() is used then the process must not do path lookups if it expects them to be within the namespace and restrict itself to pid related system calls only and so on for each of the other namespaces?

Or is it assumed that userspace will do open(/proc/<pid>/ns/<namespace>)/setns()/close() every time it makes systems calls that rely on a specific type of namespace?

Quoted 6 lines

And this reminds me another discussion, please look at
http://marc.info/?l=linux-kernel&m=138479570926192

Once again, this is just an idea to provoke more discussion. I am starting to think that perhaps we need pid_ns->umh_helper (init by default). And PR_SET_NS_UMH_HELPER.

Yeah, I'll need to digest that for a while.

Quoted 9 lines

How does one correctly set the namespace in user space since each of the /proc/<pid>/ns/<namespace> will use a slightly different proc_ns_operations install function?

Are we saying that, for example, if open(/proc/<pid>/ns/pid)/setns() is used then the process must not do path lookups if it expects them to be within the namespace and restrict itself to pid related system calls only and so on for each of the other namespaces?

In userspace you can only set the pid namespace for new children. You can never change your own pid namespace. Because actually changing a processes pid is too nasty to contemplate, or implement and because in a login daemon context having your first child be the initial process of the pid namespace is actually what is desirable.

Quoted 3 lines · Oleg Nesterov

and probably we also need this for coredump helpers, we want them to be per-namespace.

To save me some time could you point me to some of the related code please. I don't normally play in that area.

Quoted 3 lines

kernel/kmod.c int call_usermodehelper(char *path, char **argv, char **envp, int wait) · line 652

Quoted 1 line

kernel/kmod.c +1 -0

+	switch_task_namespaces(current, ns);

This doesn't look sane because this won't switch task_active_pid_ns().

I wondered about that too but I didn't design the open()/setns()

Quoted 2 lines

And otoh. If we actually want to use the caller's mnt_ns/namespaces we could simply fork/reparent a child which will do execve ?

Are you saying that the user space program should be modified to do this?