On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote: > Luis Chamberlain <mcgrof@xxxxxxxxxx> writes: > > Thanks for the description of how to run into the issue described but > > is there also a practical use case today where this is happening? I ask > > as it would be good to know the severity of the issue in the real world > > today. > > People trying to run containers without a root user in the container. > It atypical but something doable. My question was if there are generic tools / propreitary tools which are doing this widely *today*. Or is this just a custom setup some folks use? > We spoke about this at LPC. And this is the correct behavioral change. > > The problem is there is a default value for i_uid and i_gid that is > correct in the general case. That default value is not corect for > sysctl, because proc is weird. As the sysctl permission check in > test_perm are all against GLOBAL_ROOT_UID and GLOBAL_ROOT_GID we did not > notice that i_uid and i_gid were being set wrong. > > So all this patch does is fix the default values i_uid and i_gid. > > The commit comment seems worth cleaning up. But for the > content of the code. The logic seems sensible then, but are we implicating what a container does with its sysctl values onto the entire system? If so, sure, it seems you want this for networking purposes as there are a series of sysctl values a container may want to muck with, but are we sure we want the same for *all* sysctl entries? Luis
