Hi Tony,
On 11/7/2023 16:28, Luck, Tony wrote:
>> @@ -1042,7 +1060,7 @@ struct dentry *debugfs_create_blob(const char *name, umode_t mode,
>> struct dentry *parent,
>> struct debugfs_blob_wrapper *blob)
>> {
>> - return debugfs_create_file_unsafe(name, mode & 0444, parent, blob, &fops_blob);
>> + return debugfs_create_file_unsafe(name, mode, parent, blob, &fops_blob);
>> }
>
> The minimalist change here would be to s/0444/0666/
>
Just realized that s/0444/0644/ might be an even more minimalist change since you anyways,
I think, need to be root for error injection through einj. Does that sound good?
In any case, using 0666 will result in the below checkpatch warning:
[root avadnaik-linux]# ./scripts/checkpatch.pl --strict -g HEAD
WARNING: Exporting world writable files is usually an error. Consider more restrictive permissions.
#84: FILE: fs/debugfs/file.c:1063:
+ return debugfs_create_file_unsafe(name, mode & 0666, parent, blob, &fops_blob);
total: 0 errors, 1 warnings, 0 checks, 54 lines checked
Would you be okay with s/0444/0644/?
- return debugfs_create_file_unsafe(name, mode & 0444, parent, blob, &fops_blob);
+ return debugfs_create_file_unsafe(name, mode & 0644, parent, blob, &fops_blob);
> That would just allow callers to ask for writeable files without letting them
> add execute permission, or exotic modes like setuid etc.
>
> -Tony
--
Thanks,
Avadhut Naik
> > The minimalist change here would be to s/0444/0666/
> >
> Just realized that s/0444/0644/ might be an even more minimalist change since you anyways,
> I think, need to be root for error injection through einj. Does that sound good?
You need write access. I don't think you need to be root. E.g. a validation system might
set up an "einj" group and "chmod" all these files to 0664. But that's nitpicking.
>
> In any case, using 0666 will result in the below checkpatch warning:
>
> [root avadnaik-linux]# ./scripts/checkpatch.pl --strict -g HEAD
> WARNING: Exporting world writable files is usually an error. Consider more restrictive permissions.
> #84: FILE: fs/debugfs/file.c:1063:
> + return debugfs_create_file_unsafe(name, mode & 0666, parent, blob, &fops_blob);
>
> total: 0 errors, 1 warnings, 0 checks, 54 lines checked
The warning is dubious. This code isn't necessarily exporting a world writeable file. But
it does allow a caller of this routine to do that.
>
> Would you be okay with s/0444/0644/?
> - return debugfs_create_file_unsafe(name, mode & 0444, parent, blob, &fops_blob);
> + return debugfs_create_file_unsafe(name, mode & 0644, parent, blob, &fops_blob);
Yes. This is fine (better). Make sure to mention in the commit comment that this allows
callers to create files writeable by owner.
-Tony
On 11/16/2023 12:44, Luck, Tony wrote:
>>> The minimalist change here would be to s/0444/0666/
>>>
>> Just realized that s/0444/0644/ might be an even more minimalist change since you anyways,
>> I think, need to be root for error injection through einj. Does that sound good?
>
> You need write access. I don't think you need to be root. E.g. a validation system might
> set up an "einj" group and "chmod" all these files to 0664. But that's nitpicking.
>
>>
>> In any case, using 0666 will result in the below checkpatch warning:
>>
>> [root avadnaik-linux]# ./scripts/checkpatch.pl --strict -g HEAD
>> WARNING: Exporting world writable files is usually an error. Consider more restrictive permissions.
>> #84: FILE: fs/debugfs/file.c:1063:
>> + return debugfs_create_file_unsafe(name, mode & 0666, parent, blob, &fops_blob);
>>
>> total: 0 errors, 1 warnings, 0 checks, 54 lines checked
>
> The warning is dubious. This code isn't necessarily exporting a world writeable file. But
> it does allow a caller of this routine to do that.
>
>>
>> Would you be okay with s/0444/0644/?
>
>> - return debugfs_create_file_unsafe(name, mode & 0444, parent, blob, &fops_blob);
>> + return debugfs_create_file_unsafe(name, mode & 0644, parent, blob, &fops_blob);
>
>
> Yes. This is fine (better). Make sure to mention in the commit comment that this allows
> callers to create files writeable by owner.
>
Will do. Thanks for the confirmation!
> -Tony
>
>
--
Thanks,
Avadhut Naik