On 02/20/2018 06:17 PM, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long <longman@xxxxxxxxxx> wrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One may >> try to write extreme parameter values to see if they get clamped. >> To make it easier, a warning with the expected range will now be >> printed in the kernel ring buffer when a clamped sysctl parameter >> receives an out of range value. > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? > Good point. Beside adding security check, another alternative is to use some kind of warn_once() for each sysctl parameter. That will limit the amount of spamming that is possible. It will require adding a flag to the ctl_table to mark an entry as warned. I think that will be less tricky than adding permission check. I can also use the new flag to designate that a sysctl parameter need to be clamped to the range instead of failing when out of range. With that, I don't need to introduce new clamping APIs. I can use the existing ones. I will work on v2 patch with that change. Thanks, Longman
