linux-kernel - Re: [PATCH 1/7] ns: proc files for namespace naming policy.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1oc38luj0.fsf@fess.ebiederm.org>
Date:	Wed, 11 May 2011 15:52:35 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Nathan Lynch <ntl@...ox.com>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	jamal <hadi@...erus.ca>, Daniel Lezcano <daniel.lezcano@...e.fr>,
	Linux Containers <containers@...ts.osdl.org>,
	Renato Westphal <renatowestphal@...il.com>
Subject: Re: [PATCH 1/7] ns: proc files for namespace naming policy.

Nathan Lynch <ntl@...ox.com> writes:

> Hi Eric,
>
> A few comments on your patch set.
>
>
> On Fri, 2011-05-06 at 19:24 -0700, Eric W. Biederman wrote:
>> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
>> index d15aa1b..74b48cf 100644
>> --- a/fs/proc/inode.c
>> +++ b/fs/proc/inode.c
>> @@ -28,6 +28,7 @@ static void proc_evict_inode(struct inode *inode)
>>  {
>>  	struct proc_dir_entry *de;
>>  	struct ctl_table_header *head;
>> +	const struct proc_ns_operations *ns_ops;
>>  
>>  	truncate_inode_pages(&inode->i_data, 0);
>>  	end_writeback(inode);
>> @@ -44,6 +45,10 @@ static void proc_evict_inode(struct inode *inode)
>>  		rcu_assign_pointer(PROC_I(inode)->sysctl, NULL);
>>  		sysctl_head_put(head);
>>  	}
>> +	/* Release any associated namespace */
>> +	ns_ops = PROC_I(inode)->ns_ops;
>> +	if (ns_ops && ns_ops->put)
>> +		ns_ops->put(PROC_I(inode)->ns);
>
> Is it ever valid for ns_ops->put to be null?  If not, I suggest removing
> the check.
>
>
>> diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
>> new file mode 100644
>> index 0000000..6ae9f07
>> --- /dev/null
>> +++ b/fs/proc/namespaces.c
>
> ...
>
>> +static struct dentry *proc_ns_dir_lookup(struct inode *dir,
>> +				struct dentry *dentry, struct nameidata *nd)
>> +{
>> +	struct dentry *error;
>> +	struct task_struct *task = get_proc_task(dir);
>> +	const struct proc_ns_operations **entry, **last;
>> +	unsigned int len = dentry->d_name.len;
>> +
>> +	error = ERR_PTR(-ENOENT);
>> +
>> +	if (!task)
>> +		goto out_no_task;
>> +
>> +	error = ERR_PTR(-EPERM);
>> +	if (!ptrace_may_access(task, PTRACE_MODE_READ))
>> +		goto out;
>> +
>> +	last = &ns_entries[ARRAY_SIZE(ns_entries) - 1];
>> +	for (entry = ns_entries; entry <= last; entry++) {
>> +		if (strlen((*entry)->name) != len)
>> +			continue;
>> +		if (!memcmp(dentry->d_name.name, (*entry)->name, len))
>> +			break;
>> +	}
>> +	if (entry > last)
>> +		goto out;
>
> This returns EPERM when it should return ENOENT?

Good catch.

And fixed now.

>>  union proc_op {
>>  	int (*proc_get_link)(struct inode *, struct path *);
>>  	int (*proc_read)(struct task_struct *task, char *page);
>> @@ -268,6 +284,8 @@ struct proc_inode {
>>  	struct proc_dir_entry *pde;
>>  	struct ctl_table_header *sysctl;
>>  	struct ctl_table *sysctl_entry;
>> +	void *ns;
>> +	const struct proc_ns_operations *ns_ops;
>>  	struct inode vfs_inode;
>>  };
>
> Not that I have any better ideas, but it seems a bit undesirable to
> increase the size of proc_inode for this one purpose.

Of the options I could think of this was the cleanest, and proc_inode
is just a caching data structure which means that the effect should be
comparatively minimal.

That said I won't oppose a change at some point to reduce the
proc_inode, there are a lot of fields that are not used for most proc
entries.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/