Re: [PATCH 00/23] Removal of binary sysctl support

[ebiederm@xmission.com (Eric W. Biederman)]

Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:

> Hello.
>
> Eric W. Biederman wrote:
>> Tetsuo Handa writes:
>> 
>> > Eric W. Biederman wrote:
>> >> There has been a gradual transition from the assumption that the table ends with
>> >> !ctl_name to the assumption that procname == NULL.  There is no sysctl entry
>> >> with a valid ctl_name without a valid procname.
>> >
>> > I see. Then, please add below one to your patchset.
>> 
>> I have been looking at this and in the sysctl tree I am now going through
>> the vfs for all of the the operations on /proc/sys.  I believe that means
>> we can completely remove the sysctl special case in tomoyo.  Like I have
>> in the patch below.
>> 
>> Will that work?
>> 
>> Eric
>
> If you remove sysctl(2) from kernel and let userland libraries emulate
>
> 	static int name[] = { CTL_NET, NET_IPV4, NET_IPV4_LOCAL_PORT_RANGE };
> 	int buffer[2] = { 0, 0 };
> 	int size = sizeof(buffer);
> 	sysctl(name, 3, buffer, &size, 0, 0);
>
> like
>
> 	FILE *fp = fopen("/proc/sys/net/ipv4/ip_local_port_range", "r");
> 	int buffer[2] = { 0, 0 };
> 	fscanf(fp, "%u %u", &buffer[0], &buffer[1]);
> 	fclose(fp);
>
> or you modify sysctl(2) to call security_dentry_open() rather than
> security_sysctl(), we can completely remove the sysctl special case in tomoyo.

I have done something very close, the emulation is in the kernel not
user space, but the idea is the same.

The relevant bits of binary_sysctl() (from my sysctl tree) are:
	mnt = current->nsproxy->pid_ns->proc_mnt;
	result = vfs_path_lookup(mnt->mnt_root, mnt, pathname, 0, &nd);
	if (result)
		goto out_putname;

	result = may_open(&nd.path, acc_mode, fmode);
	if (result)
		goto out_putpath;

	file = dentry_open(nd.path.dentry, nd.path.mnt, flags, current_cred());
	result = PTR_ERR(file);
	if (IS_ERR(file))
		goto out_putname;

 dentry_open calls __dentry_open which calls security_dentry_open.

The twist that may get this into trouble is that I am going through
the internal vfs mount of /proc instead of the normal mount of proc.
So you will see paths like "/sys/net/ipv4/ip_local_port_range" instead
of "/proc/sys/net/ipv4/ip_local_port_range".  I don't know how the
choice of mount points affects you.

Eric