linux-kernel - Re: [PATCH v3] SUNRPC: set desired file system root before connecting local transports

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]

Date:	Mon, 12 Nov 2012 12:37:54 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>,
	"Trond.Myklebust@...app.com" <Trond.Myklebust@...app.com>
CC:	Christoph Hellwig <hch@...radead.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...nvz.org" <devel@...nvz.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH v3] SUNRPC: set desired file system root before connecting
 local transports

07.11.2012 22:33, J. Bruce Fields пишет:
> On Tue, Nov 06, 2012 at 08:36:05AM -0500, J. Bruce Fields wrote:
>> On Tue, Nov 06, 2012 at 08:10:18AM -0500, Christoph Hellwig wrote:
>>> On Tue, Nov 06, 2012 at 08:07:06AM -0500, J. Bruce Fields wrote:
>>>> So you're worried that a bug in the nfs code could modify the root and
>>>> then not restore it?
>>>
>>> At least the link you pointed to earlier never sets it back.
>>
>> This? http://thread.gmane.org/gmane.linux.kernel/1259986/focus=47687
>>
>> 	+	get_fs_root(current->fs, &root);
>> 	+	set_fs_root(current->fs, &transport->root);
>> 	+
>> 	 	status = xs_local_finish_connecting(xprt, sock);
>> 	+
>> 	+	set_fs_root(current->fs, &root);
>> 	+	path_put(&root);
>>
>>> Instead
>>> of messing with it I'd rather have the sunrpc code use vfs_path_lookup
>>> and not care about current->fs->root at all.
>>
>> The annoyance is that the lookup happens somewhere lower down in the
>> networking code (net/unix/af_unix.c:unix_find_other, I think).  So we'd
>> need some new (internal) API.  We'd likely be the only user of that new
>> API.
>
> So, if the only drawback is really just the risk of introducing a bug
> that leaves the fs_root changed--the above seems simple enough for that
> not to be a great risk, right?
>

If we unshare rpciod fs struct (which is exported already), then we won't affect 
other kthreads by root swapping.
But would be great to hear Trond's opinion about this approach.

Trond, could you tell us your feeling about all this?

> Is there any other hazard to doing this that people can think of?
>
> --b.
>


-- 
Best regards,
Stanislav Kinsbursky
--
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/