Second attempt at contained helper execution

From previous discussion seperation between the caller and the

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

Both containerized NFS client and NFS server need the ability to execute a binary in a container's context. To do this use the init process of the callers environment is used to setup the namespaces in the same way the root init process is used otherwise.

Signed-off-by Ian Kent <[email protected]>

Cc Benjamin Coddington <[email protected]>

Cc Al Viro <[email protected]>

Cc J. Bruce Fields <[email protected]>

Cc David Howells <[email protected]>

Cc Trond Myklebust <[email protected]>

Cc Oleg Nesterov <[email protected]>

Cc Eric W. Biederman <[email protected]>

Cc Jeff Layton <[email protected]>

---
 include/linux/kmod.h |   17 +++++++
 kernel/kmod.c        |  119 +++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 133 insertions(+), 3 deletions(-)

include/linux/kmod.h +17 -0

index 15bdeed..487e68e 100644
@@ -52,6 +52,7 @@ struct file;
 #define UMH_WAIT_EXEC	1	/* wait for the exec, but not the process */
 #define UMH_WAIT_PROC	2	/* wait for the process to complete */
 #define UMH_KILLABLE	4	/* wait for EXEC/PROC killable */
+#define UMH_USE_NS	8	/* exec using caller's init namespace */
 
 struct subprocess_info {
 	struct work_struct work;

@@ -69,6 +70,22 @@ struct subprocess_info {
 extern int
 call_usermodehelper(char *path, char **argv, char **envp, int flags);
 
+#if !defined(CONFIG_PROC_FS) || !defined(CONFIG_NAMESPACES)
+inline int umh_get_init_pid(pid_t *pid)
+{
+	*pid = 0;
+	return 0;
+}
+
+inline int umh_enter_ns(pid_t pid, struct cred *new)
+{
+	return -ENOTSUP;
+}
+#else
+int umh_get_init_pid(pid_t *pid);
+int umh_enter_ns(pid_t pid, struct cred *new);
+#endif
+
 extern struct subprocess_info *
 call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask,
 			  int (*init)(struct subprocess_info *info, struct cred *new),

kernel/kmod.c +18 -0

index 14c0188..2179e58 100644
@@ -582,6 +582,97 @@ unlock:
 }
 EXPORT_SYMBOL(call_usermodehelper_exec);
 
+#if defined(CONFIG_PROC_FS) && defined(CONFIG_NAMESPACES)
+#define NS_PATH_MAX	35
+#define NS_PATH_FMT	"%lu/ns/%s"
+
+/* Note namespace name order is significant */
+static const char *ns_names[] = { "user", "ipc", "uts", "net", "pid", "mnt", NULL };
+
+int umh_get_init_pid(pid_t *pid)
+{
+	struct task_struct *tsk;
+	pid_t init_pid;
+
+	rcu_read_lock();
+	tsk = find_task_by_vpid(1);
+	if (tsk)
+		get_task_struct(tsk);
+	rcu_read_unlock();
+	if (!tsk)

kernel/kmod.c +74 -3

+int umh_enter_ns(pid_t pid, struct cred *new)
+{
+	char path[NS_PATH_MAX];
+	struct vfsmount *mnt;
+	const char *name;
+	int err = 0;
+
+	/*
+	 * The user mode thread runner runs in the root init namespace
+	 * so it will see all system pids.
+	 */
+	mnt = task_active_pid_ns(current)->proc_mnt;
+
+	for (name = ns_names[0]; *name; name++) {
+		struct file *this;
+		int len;
+
+		len = snprintf(path,
+			       NS_PATH_MAX, NS_PATH_FMT,
+			       (unsigned long) pid, name);
+		if (len >= NS_PATH_MAX) {
+			err = -ENAMETOOLONG;
+			break;
+		}
+
+		this = file_open_root(mnt->mnt_root, mnt, path, O_RDONLY);
+		if (unlikely(IS_ERR(this))) {
+			err = PTR_ERR(this);
+			break;
+		}
+
+		err = setns_inode(file_inode(this), 0);
+		fput(this);
+		if (err)
+			break;
+	}
+
+	return err;
+}
+EXPORT_SYMBOL(umh_enter_ns);
+
+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	pid_t *init_pid = (pid_t *) info->data;
+
+	return umh_enter_ns(*init_pid, new);
+}
+
+static void umh_free_ns(struct subprocess_info *info)
+{
+	kfree(info->data);
+}
+#else
+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	return 0;
+}
+
+static void umh_free_ns(struct subprocess_info *info)
+{
+}
+#endif
+
 /**
  * call_usermodehelper() - prepare and start a usermode application
  * @path: path to usermode executable

@@ -599,11 +690,33 @@ int call_usermodehelper(char *path, char **argv, char **envp, int flags)
 {
 	struct subprocess_info *info;
 	gfp_t gfp_mask = (flags == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
+	unsigned int use_ns = flags & UMH_USE_NS;
+	pid_t init_pid = 0;
+	pid_t *pid = NULL;
 
-	info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
-					 NULL, NULL, NULL);
-	if (info == NULL)
+	if (use_ns) {
+		int ret = umh_get_init_pid(&init_pid);
+		if (ret)
+			return ret;
+	}
+
+	if (!init_pid)
+		info = call_usermodehelper_setup(path, argv, envp,

kernel/kmod.c +4 -0

+	if (info == NULL) {
+		if (pid)
+			kfree(pid);
 		return -ENOMEM;
+	}
 
 	return call_usermodehelper_exec(info, flags);
 }

Quoted 89 lines · On Wed, 14 Jan 2015 17:32:43 +0800 Ian Kent <[email protected]> wrote:

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

Both containerized NFS client and NFS server need the ability to execute a binary in a container's context. To do this use the init process of the callers environment is used to setup the namespaces in the same way the root init process is used otherwise.

Signed-off-by Ian Kent <[email protected]>

Cc Benjamin Coddington <[email protected]>

Cc Al Viro <[email protected]>

Cc J. Bruce Fields <[email protected]>

Cc David Howells <[email protected]>

Cc Trond Myklebust <[email protected]>

Cc Oleg Nesterov <[email protected]>

Cc Eric W. Biederman <[email protected]>

Cc Jeff Layton <[email protected]>

---
 include/linux/kmod.h |   17 +++++++
 kernel/kmod.c        |  119 +++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 133 insertions(+), 3 deletions(-)

include/linux/kmod.h +17 -0

index 15bdeed..487e68e 100644
@@ -52,6 +52,7 @@ struct file;
 #define UMH_WAIT_EXEC	1	/* wait for the exec, but not the process */
 #define UMH_WAIT_PROC	2	/* wait for the process to complete */
 #define UMH_KILLABLE	4	/* wait for EXEC/PROC killable */
+#define UMH_USE_NS	8	/* exec using caller's init namespace */
 
 struct subprocess_info {
 	struct work_struct work;

@@ -69,6 +70,22 @@ struct subprocess_info {
 extern int
 call_usermodehelper(char *path, char **argv, char **envp, int flags);
 
+#if !defined(CONFIG_PROC_FS) || !defined(CONFIG_NAMESPACES)
+inline int umh_get_init_pid(pid_t *pid)
+{
+	*pid = 0;
+	return 0;
+}
+
+inline int umh_enter_ns(pid_t pid, struct cred *new)
+{
+	return -ENOTSUP;
+}
+#else
+int umh_get_init_pid(pid_t *pid);
+int umh_enter_ns(pid_t pid, struct cred *new);
+#endif
+
 extern struct subprocess_info *
 call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask,
 			  int (*init)(struct subprocess_info *info, struct cred *new),

kernel/kmod.c +23 -0

index 14c0188..2179e58 100644
@@ -582,6 +582,97 @@ unlock:
 }
 EXPORT_SYMBOL(call_usermodehelper_exec);
 
+#if defined(CONFIG_PROC_FS) && defined(CONFIG_NAMESPACES)
+#define NS_PATH_MAX	35
+#define NS_PATH_FMT	"%lu/ns/%s"
+
+/* Note namespace name order is significant */
+static const char *ns_names[] = { "user", "ipc", "uts", "net", "pid", "mnt", NULL };
+
+int umh_get_init_pid(pid_t *pid)
+{
+	struct task_struct *tsk;
+	pid_t init_pid;
+
+	rcu_read_lock();
+	tsk = find_task_by_vpid(1);
+	if (tsk)
+		get_task_struct(tsk);
+	rcu_read_unlock();
+	if (!tsk)
+		return -ESRCH;
+	init_pid = task_pid_nr(tsk);
+	put_task_struct(tsk);
+
+	*pid = init_pid;

kernel/kmod.c unlock: · line 612

Quoted 5 lines

kernel/kmod.c +5 -0

+
+	return 0;
+}
+EXPORT_SYMBOL(umh_get_init_pid);
+

nit: pid_t == int, so you could just make this function return the pid or a negative error code instead of dealing with a return argument.

Quoted 86 lines

kernel/kmod.c +74 -3

+int umh_enter_ns(pid_t pid, struct cred *new)
+{
+	char path[NS_PATH_MAX];
+	struct vfsmount *mnt;
+	const char *name;
+	int err = 0;
+
+	/*
+	 * The user mode thread runner runs in the root init namespace
+	 * so it will see all system pids.
+	 */
+	mnt = task_active_pid_ns(current)->proc_mnt;
+
+	for (name = ns_names[0]; *name; name++) {
+		struct file *this;
+		int len;
+
+		len = snprintf(path,
+			       NS_PATH_MAX, NS_PATH_FMT,
+			       (unsigned long) pid, name);
+		if (len >= NS_PATH_MAX) {
+			err = -ENAMETOOLONG;
+			break;
+		}
+
+		this = file_open_root(mnt->mnt_root, mnt, path, O_RDONLY);
+		if (unlikely(IS_ERR(this))) {
+			err = PTR_ERR(this);
+			break;
+		}
+
+		err = setns_inode(file_inode(this), 0);
+		fput(this);
+		if (err)
+			break;
+	}
+
+	return err;
+}
+EXPORT_SYMBOL(umh_enter_ns);
+
+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	pid_t *init_pid = (pid_t *) info->data;
+
+	return umh_enter_ns(*init_pid, new);
+}
+
+static void umh_free_ns(struct subprocess_info *info)
+{
+	kfree(info->data);
+}
+#else
+static int umh_set_ns(struct subprocess_info *info, struct cred *new)
+{
+	return 0;
+}
+
+static void umh_free_ns(struct subprocess_info *info)
+{
+}
+#endif
+
 /**
  * call_usermodehelper() - prepare and start a usermode application
  * @path: path to usermode executable

@@ -599,11 +690,33 @@ int call_usermodehelper(char *path, char **argv, char **envp, int flags)
 {
 	struct subprocess_info *info;
 	gfp_t gfp_mask = (flags == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
+	unsigned int use_ns = flags & UMH_USE_NS;
+	pid_t init_pid = 0;
+	pid_t *pid = NULL;
 
-	info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
-					 NULL, NULL, NULL);
-	if (info == NULL)
+	if (use_ns) {
+		int ret = umh_get_init_pid(&init_pid);
+		if (ret)
+			return ret;
+	}
+
+	if (!init_pid)
+		info = call_usermodehelper_setup(path, argv, envp,

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

Quoted 10 lines

kernel/kmod.c +10 -0

+						 gfp_mask, NULL, NULL, NULL);
+	else {
+		pid = kmalloc(sizeof(pid_t), gfp_mask);
+		if (!pid)
+			return -ENOMEM;
+		*pid = init_pid;
+		info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
+						 umh_set_ns, umh_free_ns,
+						 pid);
+	}

Is this racy?

What guarantees that that pid will still be there (and in its correct incarnation) once you get around to spawning the helper? After all, this is just done via workqueues. Between the time that the work is scheduled and picked up by the workqueue the whole namespace could be torn down and a new process could grab that pid.

Maybe it would be better instead to deal with task_structs directly, and ensure that the correct init process task_struct is pinned until the new process is spawned? (or maybe even until it exits?)

Quoted 10 lines

kernel/kmod.c +4 -0

+	if (info == NULL) {
+		if (pid)
+			kfree(pid);
 		return -ENOMEM;
+	}
 
 	return call_usermodehelper_exec(info, flags);
 }

This series is a further attempt to find how (or even an acceptable way) to execute a usermode helper in a contained environment.

Being an attempt to find how to do this no testing has been done and won't be until a suitable approach can be agreed on, if at all.

Quoted 1 line

From previous discussion seperation between the caller and the

execution environment is required for security reasons.

It was suggested that a thread be created for each mount and be used as the basis for the execution environment. There are a number of problems with this, not the least of which is scaling to a large numbers of mounts, and there may not be a mount corresponding the the needed callback

which amounts to creating the process from the context of the caller which we don't want to do.

But now, when a usermode helper is executed the root init namespace is used and has proven to be adequate. So perhaps it will also be adequate to use the same approach for contained execution by using the container init namespace as the basis for the execution.

That's essentially all this series attempts to do.

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

There's also the rather resource heavy method that is used here to enter the target namespace which probably needs work but is out of scope for this series if in fact this approach is even acceptable.

Comments please?

---

Ian Kent (5):
nsproxy - refactor setns()
kmod - rename call_usermodehelper() flags parameter kmod - teach call_usermodehelper() to use a namespace KEYS - rename call_usermodehelper_keys() flags parameter
KEYS: exec request-key within the requesting task's init namespace

 include/linux/kmod.h        |   21 ++++++-
 include/linux/nsproxy.h     |    1 
 kernel/kmod.c               |  135 +++++++++++++++++++++++++++++++++++++++----
 kernel/nsproxy.c            |   21 ++++---
 security/keys/request_key.c |   51 ++++++++++++++--
 5 files changed, 201 insertions(+), 28 deletions(-)

--
Ian

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Quoted 10 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

Quoted 2 lines

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

At least I believe that's a problem and I agree that, once a suitable method of running helpers is found each case will need to be looked at.

Ian

Quoted 14 lines · Ian Kent

Quoted 12 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Quoted 4 lines

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

Name-id mappings should be associated with the superblock, I guess--so don't you store a pointer to the right thing there?

--b.

Quoted 7 lines

At least I believe that's a problem and I agree that, once a suitable method of running helpers is found each case will need to be looked at.

Ian

Quoted 20 lines · J. Bruce Fields

Quoted 18 lines · Ian Kent

Quoted 7 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

Quoted 5 lines

I think you have to go through each of the existing upcall examples and decide what's needed for each.

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

Quoted 2 lines

Name-id mappings should be associated with the superblock, I guess--so don't you store a pointer to the right thing there?

Quite possibly but my original point was, without an acceptable mechanism to execute the helper we can't know what might need to be done to use it.

Quoted 24 lines · Ian Kent

Quoted 22 lines · J. Bruce Fields

Quoted 11 lines · Ian Kent

Quoted 10 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

Quoted 7 lines

Quoted 2 lines

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

Name-id mappings should be associated with the superblock, I guess--so don't you store a pointer to the right thing there?

Quoted 3 lines

Quite possibly but my original point was, without an acceptable mechanism to execute the helper we can't know what might need to be done to use it.

At least for me it would be easier to review if it came with at least one example user.

Quoted 25 lines · J. Bruce Fields

Quoted 24 lines · Ian Kent

Quoted 22 lines · J. Bruce Fields

Quoted 11 lines · Ian Kent

Quoted 10 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

Quoted 7 lines

Quoted 2 lines

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

Name-id mappings should be associated with the superblock, I guess--so don't you store a pointer to the right thing there?

Quoted 6 lines

Quoted 3 lines

Quite possibly but my original point was, without an acceptable mechanism to execute the helper we can't know what might need to be done to use it.

At least for me it would be easier to review if it came with at least one example user.

Haven't seen any negative responses but perhaps people are still away over Xmas.

In the mean time it's probably a good idea to add some use cases to the series in case the approach is OK.

I'll have a look at the nfsd code and see if I can spot the places.

Quoted 36 lines · Ian Kent

Quoted 25 lines · J. Bruce Fields

Quoted 24 lines · Ian Kent

Quoted 22 lines · J. Bruce Fields

Quoted 11 lines · Ian Kent

Quoted 10 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

Quoted 7 lines

Quoted 2 lines

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

Name-id mappings should be associated with the superblock, I guess--so don't you store a pointer to the right thing there?

Quoted 6 lines

Quoted 3 lines

Quite possibly but my original point was, without an acceptable mechanism to execute the helper we can't know what might need to be done to use it.

At least for me it would be easier to review if it came with at least one example user.

Haven't seen any negative responses but perhaps people are still away over Xmas.

Quoted 4 lines

In the mean time it's probably a good idea to add some use cases to the series in case the approach is OK.

I'll have a look at the nfsd code and see if I can spot the places.

On the nfsd side it's just the one call_usermodehelper in fs/nfsd/nfs4recover.c. The tricky part is figuring out where the namespace information should come from.

Quoted 37 lines · J. Bruce Fields

Quoted 36 lines · Ian Kent

Quoted 25 lines · J. Bruce Fields

Quoted 24 lines · Ian Kent

Quoted 22 lines · J. Bruce Fields

Quoted 11 lines · Ian Kent

Quoted 10 lines · J. Bruce Fields

Quoted 6 lines · Ian Kent

Quoted 5 lines

There are other difficulties to tackle as well, such as how to decide if contained helper execution is needed. For example, if a mount has been propagated to a container or bound into the container tree (such as with the --volume option of "docker run") the root init namespace may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and decide what's needed for each.

Quoted 7 lines

Quoted 2 lines

At least for the nfsv4 idmapper I would've thought the namespace the mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was done in. It may have been propagated from another namespace or (although I don't think it works yet) bound from another container using the volumes-from docker option.

Name-id mappings should be associated with the superblock, I guess--so don't you store a pointer to the right thing there?

Quoted 6 lines

Quoted 3 lines

Quite possibly but my original point was, without an acceptable mechanism to execute the helper we can't know what might need to be done to use it.

At least for me it would be easier to review if it came with at least one example user.

Haven't seen any negative responses but perhaps people are still away over Xmas.

Quoted 8 lines

Quoted 4 lines

In the mean time it's probably a good idea to add some use cases to the series in case the approach is OK.

I'll have a look at the nfsd code and see if I can spot the places.

On the nfsd side it's just the one call_usermodehelper in fs/nfsd/nfs4recover.c. The tricky part is figuring out where the namespace information should come from.

I had a look at the nfsd code but haven't looked at the nfsdcltrack to see what it does and if it expects anything that wouldn't be available. There's also the assumption that the external application is present within the container filesystem at the same location.

The whole idea of the current approach is that the namespace information comes from the init process of the container it's executing in.

I believe that if nfsd is running in a container it should be able to function entirely within the container, except for the callback issue.

I see there's a check in the callback init function to see if the net namespace in use is the root net namespace. It looks like that check would be enough to determine that container execution is needed.

Assuming that the various locations all contain the same struct net, such as is stored in (struct nfs4_client) clp, then it's probably enough to change nfsd4_umh_cltrack_upcall() to also take net as a parameter.

Then the same check (which would be removed) used in the init function could be used to determine if the UMH_USE_NS flag needs to be passed to call_usermodehelper().

Passing the UMH_USE_NS flag to call_usermodehelper() will cause the helper to be executed within the init namespace (including the net namespace) of the container.

If that is what's needed then it might be sensible to change nfsd4_umh_cltrack_upcall() to take a structure containing parameters to keep it clean.

I could create patches to demonstrate the procedure but we probably should keep that discussion separate from this one for the moment.

Ian