Skip to contentSkip to conversation

debugfs: debugfs_create_* shouldn't be checking permissions

PATCH In review J. Bruce Fields 5 participants 6 messages Mar 30, 2015 2 messages not in the archive

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 debugfs: debugfs_create_* shouldn't be checking permissions

From: "J. Bruce Fields" <[email protected]>

Subject: [PATCH] debugfs: debugfs_create_* shouldn't be checking permissions

Debugfs files and and directories are created by kernel subsystems not directly by users, so we shouldn't be using lookup_one_len, which checks permissions.

This was causing krb5 mounts to fail to Fedora servers using gss-proxy if selinux was enabled, on kernels since 388f0c776781 "sunrpc: add a debugfs rpc_xprt directory with an info file in it", which creates a new debugfs directory for each new rpc client.

---
 fs/debugfs/inode.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

I swiped this code fragment from net/sunrpc/rpc_pipe.c, and it's gotten only minimal testing. (It does fix krb5 mounts, though.)

fs/debugfs/inode.c +13 -4
index 96400ab42d13..75e5daa6a63f 100644
@@ -251,6 +251,7 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 {
 	struct dentry *dentry;
 	int error;
+	struct qstr q = QSTR_INIT(name, strlen(name));
 
 	pr_debug("debugfs: creating file '%s'\n",name);
 
@@ -268,11 +269,19 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 		parent = debugfs_mount->mnt_root;
 
 	mutex_lock(&parent->d_inode->i_mutex);
-	dentry = lookup_one_len(name, parent, strlen(name));
-	if (!IS_ERR(dentry) && dentry->d_inode) {
+	dentry = d_hash_and_lookup(parent, &q);
+	if (!dentry) {
+		dentry = d_alloc(parent, &q);
+		if (!dentry) {
+			dentry = ERR_PTR(-ENOMEM);
+			goto out;
+		}
+	}
+	if (dentry->d_inode) {
 		dput(dentry);
 		dentry = ERR_PTR(-EEXIST);
 	}
+out:
 	if (IS_ERR(dentry))
 		mutex_unlock(&parent->d_inode->i_mutex);
 	return dentry;
@@ -340,7 +349,7 @@ struct dentry *debugfs_create_file(const char *name, umode_t mode,
 	inode->i_mode = mode;
 	inode->i_fop = fops ? fops : &debugfs_file_operations;
 	inode->i_private = data;
-	d_instantiate(dentry, inode);
+	d_add(dentry, inode);
 	fsnotify_create(dentry->d_parent->d_inode, dentry);
 	return end_creating(dentry);
 }
@@ -422,7 +431,7 @@ struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
 
 	/* directory inodes start off with i_nlink == 2 (for "." entry) */
 	inc_nlink(inode);
-	d_instantiate(dentry, inode);
+	d_add(dentry, inode);
 	inc_nlink(dentry->d_parent->d_inode);
 	fsnotify_mkdir(dentry->d_parent->d_inode, dentry);
 	return end_creating(dentry);
Signature · 6 lines
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 4 lines · J. Bruce Fields

From: "J. Bruce Fields" <[email protected]>

Subject: [PATCH] debugfs: debugfs_create_* shouldn't be checking permissions

Quoted 8 lines

Debugfs files and and directories are created by kernel subsystems not directly by users, so we shouldn't be using lookup_one_len, which checks permissions.

This was causing krb5 mounts to fail to Fedora servers using gss-proxy if selinux was enabled, on kernels since 388f0c776781 "sunrpc: add a debugfs rpc_xprt directory with an info file in it", which creates a new debugfs directory for each new rpc client.

No kernel code should care / fail if a debugfs function fails, so please fix up the sunrpc code first.

Quoted 29 lines
---
 fs/debugfs/inode.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

I swiped this code fragment from net/sunrpc/rpc_pipe.c, and it's gotten only minimal testing. (It does fix krb5 mounts, though.)

fs/debugfs/inode.c +1 -1
index 96400ab42d13..75e5daa6a63f 100644
@@ -251,6 +251,7 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 {
 	struct dentry *dentry;
 	int error;
+	struct qstr q = QSTR_INIT(name, strlen(name));
 
 	pr_debug("debugfs: creating file '%s'\n",name);
 
@@ -268,11 +269,19 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 		parent = debugfs_mount->mnt_root;
 
 	mutex_lock(&parent->d_inode->i_mutex);
-	dentry = lookup_one_len(name, parent, strlen(name));

fs/debugfs/inode.c static struct dentry *start_creating(const char *name, struct dentry *parent) · line 280

Quoted 10 lines
fs/debugfs/inode.c +9 -1
-	if (!IS_ERR(dentry) && dentry->d_inode) {
+	dentry = d_hash_and_lookup(parent, &q);
+	if (!dentry) {
+		dentry = d_alloc(parent, &q);
+		if (!dentry) {
+			dentry = ERR_PTR(-ENOMEM);
+			goto out;
+		}
+	}
+	if (dentry->d_inode) {

No, I'd rather not "open code" lookup_one_len() if at all possible please.

What exactly is the problem here that the sunrpc code is failing from? Is it just interacting with selinux? How is the debugfs code to blame here?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · J. Bruce Fields

From: "J. Bruce Fields" <[email protected]>

Subject: [PATCH] debugfs: debugfs_create_* shouldn't be checking permissions

Debugfs files and and directories are created by kernel subsystems not directly by users, so we shouldn't be using lookup_one_len, which checks permissions.

Quoted 7 lines
Quoted 4 lines

This was causing krb5 mounts to fail to Fedora servers using gss-proxy if selinux was enabled, on kernels since 388f0c776781 "sunrpc: add a debugfs rpc_xprt directory with an info file in it", which creates a new debugfs directory for each new rpc client.

No kernel code should care / fail if a debugfs function fails, so please fix up the sunrpc code first.

The sunrpc code is using debugfs to keep a list of all rpc clients together with some basic information about each one.

If the permissions issue is fixed then I think the only possible failures are lack of debugfs support and ENOMEM?

If there are situations where ENOMEM's actually possible, I'd worry a bit about this debugging information becoming unreliable after you go through some extreme memory shortage (possibly because that's what was necessary to reproduce the bug you're chasing).

But, I don't know, maybe I'm excessively paranoid; Jeff?

Quoted 43 lines
Quoted 28 lines
---
 fs/debugfs/inode.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

I swiped this code fragment from net/sunrpc/rpc_pipe.c, and it's gotten only minimal testing. (It does fix krb5 mounts, though.)

fs/debugfs/inode.c +1 -1
index 96400ab42d13..75e5daa6a63f 100644
@@ -251,6 +251,7 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 {
 	struct dentry *dentry;
 	int error;
+	struct qstr q = QSTR_INIT(name, strlen(name));
 
 	pr_debug("debugfs: creating file '%s'\n",name);
 
@@ -268,11 +269,19 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 		parent = debugfs_mount->mnt_root;
 
 	mutex_lock(&parent->d_inode->i_mutex);
-	dentry = lookup_one_len(name, parent, strlen(name));

fs/debugfs/inode.c static struct dentry *start_creating(const char *name, struct dentry *parent) · line 280

Quoted 10 lines
fs/debugfs/inode.c +9 -1
-	if (!IS_ERR(dentry) && dentry->d_inode) {
+	dentry = d_hash_and_lookup(parent, &q);
+	if (!dentry) {
+		dentry = d_alloc(parent, &q);
+		if (!dentry) {
+			dentry = ERR_PTR(-ENOMEM);
+			goto out;
+		}
+	}
+	if (dentry->d_inode) {

No, I'd rather not "open code" lookup_one_len() if at all possible please.

Quoted 1 line

What exactly is the problem here that the sunrpc code is failing from?

Sunrpc is creating a new rpc client (to talk to an rpc server).

Debugfs will fail to do that whenever the user doesn't have execute permissions on a debugfs directory. The user in this case is whoever gss-proxy's running as, but I think it could just as well be someone doing an nfs mount, for example.

Quoted 2 lines

Is it just interacting with selinux? How is the debugfs code to blame here?

As long as the debugfs directories permit "x" to everone, I guess you're only going to hit this with selinux (or some other security module).

We don't want to require updated selinux policies just because some subsystem started creating debugfs entries as a side-effect of some system call (which is what happened here).

--b.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw
Quoted 24 lines · On Mon, 30 Mar 2015 11:27:25 -0400 "J. Bruce Fields"…
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · J. Bruce Fields

From: "J. Bruce Fields" <[email protected]>

Subject: [PATCH] debugfs: debugfs_create_* shouldn't be checking permissions

Debugfs files and and directories are created by kernel subsystems not directly by users, so we shouldn't be using lookup_one_len, which checks permissions.

Quoted 7 lines
Quoted 4 lines

This was causing krb5 mounts to fail to Fedora servers using gss-proxy if selinux was enabled, on kernels since 388f0c776781 "sunrpc: add a debugfs rpc_xprt directory with an info file in it", which creates a new debugfs directory for each new rpc client.

No kernel code should care / fail if a debugfs function fails, so please fix up the sunrpc code first.

The sunrpc code is using debugfs to keep a list of all rpc clients together with some basic information about each one.

If the permissions issue is fixed then I think the only possible failures are lack of debugfs support and ENOMEM?

Quoted 7 lines

If there are situations where ENOMEM's actually possible, I'd worry a bit about this debugging information becoming unreliable after you go through some extreme memory shortage (possibly because that's what was necessary to reproduce the bug you're chasing).

But, I don't know, maybe I'm excessively paranoid; Jeff?

The debugfs files are really just nice-to-have things. I don't think you can read too much into it if they don't show up for some reason. So, I'm fine with turning those into non-fatal errors.

Quoted 55 lines
Quoted 43 lines
Quoted 28 lines
---
 fs/debugfs/inode.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

I swiped this code fragment from net/sunrpc/rpc_pipe.c, and it's gotten only minimal testing. (It does fix krb5 mounts, though.)

fs/debugfs/inode.c +1 -1
index 96400ab42d13..75e5daa6a63f 100644
@@ -251,6 +251,7 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 {
 	struct dentry *dentry;
 	int error;
+	struct qstr q = QSTR_INIT(name, strlen(name));
 
 	pr_debug("debugfs: creating file '%s'\n",name);
 
@@ -268,11 +269,19 @@ static struct dentry *start_creating(const char *name, struct dentry *parent)
 		parent = debugfs_mount->mnt_root;
 
 	mutex_lock(&parent->d_inode->i_mutex);
-	dentry = lookup_one_len(name, parent, strlen(name));

fs/debugfs/inode.c static struct dentry *start_creating(const char *name, struct dentry *parent) · line 280

Quoted 10 lines
fs/debugfs/inode.c +9 -1
-	if (!IS_ERR(dentry) && dentry->d_inode) {
+	dentry = d_hash_and_lookup(parent, &q);
+	if (!dentry) {
+		dentry = d_alloc(parent, &q);
+		if (!dentry) {
+			dentry = ERR_PTR(-ENOMEM);
+			goto out;
+		}
+	}
+	if (dentry->d_inode) {

No, I'd rather not "open code" lookup_one_len() if at all possible please.

Quoted 1 line

What exactly is the problem here that the sunrpc code is failing from?

Sunrpc is creating a new rpc client (to talk to an rpc server).

Debugfs will fail to do that whenever the user doesn't have execute permissions on a debugfs directory. The user in this case is whoever gss-proxy's running as, but I think it could just as well be someone doing an nfs mount, for example.

Quoted 2 lines

Is it just interacting with selinux? How is the debugfs code to blame here?

Quoted 8 lines

As long as the debugfs directories permit "x" to everone, I guess you're only going to hit this with selinux (or some other security module).

We don't want to require updated selinux policies just because some subsystem started creating debugfs entries as a side-effect of some system call (which is what happened here).

--b.

Right.

Signature · 5 lines
Jeff Layton <jeff.layton-7I+n7zu2hftEKMMhf/[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#7 lore raw
Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines · J. Bruce Fields

From: "J. Bruce Fields" <[email protected]>

Subject: [PATCH] debugfs: debugfs_create_* shouldn't be checking permissions

Side-note, why are you putting the Subject: again here in the body of the patch?

Just sloppy cut-and-pasting from git-format-patch output, apologies!

--b.