From: Thomas-Mich Richter <tmricht@linux.ibm.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: brueckner@linux.vnet.ibm.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent
Date: Fri, 27 Apr 2018 13:30:53 +0200 [thread overview]
Message-ID: <82a7c2a7-f8f4-0e59-a770-c3e191f9d3de@linux.ibm.com> (raw)
In-Reply-To: <20180427100600.GB12941@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3737 bytes --]
On 04/27/2018 12:06 PM, Greg KH wrote:
> On Fri, Apr 27, 2018 at 11:14:26AM +0200, Thomas-Mich Richter wrote:
>> On 04/27/2018 10:27 AM, Greg KH wrote:
>>> On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote:
>>>> Currently function debugfs_create_dir() creates a new
>>>> directory in the debugfs (usually mounted /sys/kernel/debug)
>>>> with permission rwxr-xr-x. This is hard coded.
>>>>
>>>> Change this to use the parent directory permission.
>>>>
>>>> Fixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of debugfs_get_inode() into callers")
>>>> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> ---
>>>> fs/debugfs/inode.c | 5 ++++-
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
>>>> index 13b01351dd1c..80618330d86a 100644
>>>> --- a/fs/debugfs/inode.c
>>>> +++ b/fs/debugfs/inode.c
>>>> @@ -512,7 +512,10 @@ struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
>>>> if (unlikely(!inode))
>>>> return failed_creating(dentry);
>>>>
>>>> - inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
>>>> + if(!parent)
>>>> + parent = debugfs_mount->mnt_root;
>>>> + inode->i_mode = S_IFDIR | (d_inode(parent)->i_mode
>>>> + & (S_IRWXU | S_IRWXG));
>>>> inode->i_op = &simple_dir_inode_operations;
>>>> inode->i_fop = &simple_dir_operations;
>>>>
>>>
>>> This looks ok, but is it going to change the permissions of existing
>>> stuff in ways that might breaks things, right?
>>
>> Right, but debugfs is usually mounted on /sys/kernel/debug with
>> permissions rwx to root owner. It can be changed after the mount, of course.
>> Unless this is done, the directory permissions for /sys/kernel/debug
>> will stop any descend regardless of the subdirectory permissions.
>>
>>>
>>> Have you done a before/after comparison?
>>
>> I have tested this patch on my Linux 4.17.0rc2 kernel on s390.
>> That worked well, I have not tested other systems.
>
> What do you mean by "worked well"? What were the full tree differences
> between before and after? You should be able to get this by using:
> tree -dp /sys/kernel/debug/
> and then doing a diff on the two files.
>
> thanks,
>
> greg k-h
>
Ok, this is the tree output
Before the patch:
root@s8360047 ~]# tree -dp -L 1 /sys/kernel/debug/
/sys/kernel/debug/
├── [drwxr-xr-x] bdi
├── [drwxr-xr-x] block
├── [drwxr-xr-x] dasd
├── [drwxr-xr-x] device_component
├── [drwxr-xr-x] extfrag
├── [drwxr-xr-x] hid
├── [drwxr-xr-x] kprobes
├── [drwxr-xr-x] kvm
├── [drwxr-xr-x] memblock
├── [drwxr-xr-x] pm_qos
├── [drwxr-xr-x] qdio
├── [drwxr-xr-x] s390
├── [drwxr-xr-x] s390dbf
└── [drwx------] tracing
14 directories
After the patch:
[root@s8360047 ~]# tree -dp -L 1 /sys/kernel/debug/
sys/kernel/debug/
├── [drwx------] bdi
├── [drwx------] block
├── [drwx------] dasd
├── [drwx------] device_component
├── [drwx------] extfrag
├── [drwx------] hid
├── [drwx------] kprobes
├── [drwx------] kvm
├── [drwx------] memblock
├── [drwx------] pm_qos
├── [drwx------] qdio
├── [drwx------] s390
├── [drwx------] s390dbf
└── [drwx------] tracing
14 directories
[root@s8360047 ~]#
I attached the diff of the full tree before and after the patch.
--
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: treefull.diff --]
[-- Type: text/x-patch; name="treefull.diff", Size: 3980 bytes --]
2,52c2,52
< ├── [drwxr-xr-x] bdi
< │ ├── [drwxr-xr-x] 1:0
< │ ├── [drwxr-xr-x] 1:1
< │ ├── [drwxr-xr-x] 1:10
< │ ├── [drwxr-xr-x] 1:11
< │ ├── [drwxr-xr-x] 1:12
< │ ├── [drwxr-xr-x] 1:13
< │ ├── [drwxr-xr-x] 1:14
< │ ├── [drwxr-xr-x] 1:15
< │ ├── [drwxr-xr-x] 1:2
< │ ├── [drwxr-xr-x] 1:3
< │ ├── [drwxr-xr-x] 1:4
< │ ├── [drwxr-xr-x] 1:5
< │ ├── [drwxr-xr-x] 1:6
< │ ├── [drwxr-xr-x] 1:7
< │ ├── [drwxr-xr-x] 1:8
< │ ├── [drwxr-xr-x] 1:9
< │ └── [drwxr-xr-x] 94:0
< ├── [drwxr-xr-x] block
< ├── [drwxr-xr-x] dasd
< │ ├── [drwxr-xr-x] 0.0.e18a
< │ ├── [drwxr-xr-x] dasda
< │ └── [drwxr-xr-x] global
< ├── [drwxr-xr-x] device_component
< ├── [drwxr-xr-x] extfrag
< ├── [drwxr-xr-x] hid
< ├── [drwxr-xr-x] kprobes
< ├── [drwxr-xr-x] kvm
< ├── [drwxr-xr-x] memblock
< ├── [drwxr-xr-x] pm_qos
< ├── [drwxr-xr-x] qdio
< │ └── [drwxr-xr-x] 0.0.f5f2
< ├── [drwxr-xr-x] s390
< │ └── [drwxr-xr-x] stsi
< ├── [drwxr-xr-x] s390dbf
< │ ├── [drwxr-xr-x] 0.0.e18a
< │ ├── [drwxr-xr-x] cio_crw
< │ ├── [drwxr-xr-x] cio_msg
< │ ├── [drwxr-xr-x] cio_trace
< │ ├── [drwxr-xr-x] dasd
< │ ├── [drwxr-xr-x] kvm-trace
< │ ├── [drwxr-xr-x] lgr
< │ ├── [drwxr-xr-x] qdio_0.0.f5f2
< │ ├── [drwxr-xr-x] qdio_error
< │ ├── [drwxr-xr-x] qdio_setup
< │ ├── [drwxr-xr-x] qeth_card_0.0.f5f0
< │ ├── [drwxr-xr-x] qeth_control
< │ ├── [drwxr-xr-x] qeth_msg
< │ ├── [drwxr-xr-x] qeth_setup
< │ ├── [drwxr-xr-x] vmcp
< │ └── [drwxr-xr-x] vmur
---
> ├── [drwx------] bdi
> │ ├── [drwx------] 1:0
> │ ├── [drwx------] 1:1
> │ ├── [drwx------] 1:10
> │ ├── [drwx------] 1:11
> │ ├── [drwx------] 1:12
> │ ├── [drwx------] 1:13
> │ ├── [drwx------] 1:14
> │ ├── [drwx------] 1:15
> │ ├── [drwx------] 1:2
> │ ├── [drwx------] 1:3
> │ ├── [drwx------] 1:4
> │ ├── [drwx------] 1:5
> │ ├── [drwx------] 1:6
> │ ├── [drwx------] 1:7
> │ ├── [drwx------] 1:8
> │ ├── [drwx------] 1:9
> │ └── [drwx------] 94:0
> ├── [drwx------] block
> ├── [drwx------] dasd
> │ ├── [drwx------] 0.0.e18a
> │ ├── [drwx------] dasda
> │ └── [drwx------] global
> ├── [drwx------] device_component
> ├── [drwx------] extfrag
> ├── [drwx------] hid
> ├── [drwx------] kprobes
> ├── [drwx------] kvm
> ├── [drwx------] memblock
> ├── [drwx------] pm_qos
> ├── [drwx------] qdio
> │ └── [drwx------] 0.0.f5f2
> ├── [drwx------] s390
> │ └── [drwx------] stsi
> ├── [drwx------] s390dbf
> │ ├── [drwx------] 0.0.e18a
> │ ├── [drwx------] cio_crw
> │ ├── [drwx------] cio_msg
> │ ├── [drwx------] cio_trace
> │ ├── [drwx------] dasd
> │ ├── [drwx------] kvm-trace
> │ ├── [drwx------] lgr
> │ ├── [drwx------] qdio_0.0.f5f2
> │ ├── [drwx------] qdio_error
> │ ├── [drwx------] qdio_setup
> │ ├── [drwx------] qeth_card_0.0.f5f0
> │ ├── [drwx------] qeth_control
> │ ├── [drwx------] qeth_msg
> │ ├── [drwx------] qeth_setup
> │ ├── [drwx------] vmcp
> │ └── [drwx------] vmur
next prev parent reply other threads:[~2018-04-27 11:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 8:07 [PATCH] inode: debugfs_create_dir uses mode permission from parent Thomas Richter
2018-04-27 8:27 ` Greg KH
2018-04-27 9:14 ` Thomas-Mich Richter
2018-04-27 10:06 ` Greg KH
2018-04-27 11:30 ` Thomas-Mich Richter [this message]
2018-04-27 11:47 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82a7c2a7-f8f4-0e59-a770-c3e191f9d3de@linux.ibm.com \
--to=tmricht@linux.ibm.com \
--cc=brueckner@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).