Messages in this thread | | | From | Nicholas Johnson <> | Subject | Re: [PATCH v1 1/3] nvmem: Add support for write-only instances | Date | Thu, 27 Feb 2020 14:46:16 +0000 |
| |
On Tue, Feb 25, 2020 at 05:43:43PM +0200, Mika Westerberg wrote: > On Tue, Feb 25, 2020 at 03:30:22PM +0000, Nicholas Johnson wrote: > > > Actually I think maybe we make this one only writeable by root, in other > > > words it would always require ->root_only to be set. > > There is a world-accessible rw entry already, which would, if anything, > > be even more dangerous than a world writable entry. However, there could > > be a hypothetical use case. I agree it is unlikely to be required, but > > who knows? > > You mean 0644 entry? That should be fine as it is not writable by anyone > else than the owner (root in this case). Oops, you are right. I glossed over this and in my head thought it was 0666 for some reason, and that is why mine was 0222. Sorry for the confusion. :(
My 0222 would have to become 0200 which would be the same as the root-only one, because 0244 would be utter nonsense.
> > > Based on your statement that no sysfs should ever be world-writable, > > should I be trying to remove the world-accessible rw as well? > > No I don't think it is necesary. Just let's not add attributes that > anyone can write without good reasoning ;-) I can change nvmem_register() to return NULL if nvmem_sysfs_get_groups() returns NULL and that way I can return NULL from nvmem_sysfs_get_groups() in the instances we do not want to honour. This will also remove the need for me to WARN_ON when neither reg_read nor reg_write are provided - I can just return NULL.
I could also change the "root_only" flag to be named "world_readable" and invert the logic. That way I can deny world writable and still be in the clear. This would make me happy about denying world-writable requests, because the variable being false would no longer imply world-writable privileges. I feel like "world_readable" is a more accurate description of what the variable is intended for. This can be a single commit with no functional changes (easy sign-off) at the start of the series.
Srinivas, please offer your opinion on the above proposals, if you have one. :)
I will aim for 2020-03-02 (Monday) for PATCH v2, to give myself adequate time to reflect on feedback and to try to get it right.
Thanks!
Kind regards, Nicholas
| |