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: <519EFE46.2070507@parallels.com>
Date:	Fri, 24 May 2013 09:44:38 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
CC:	Jeff Layton <jlayton@...hat.com>,
	Boaz Harrosh <bharrosh@...asas.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	<viro@...iv.linux.org.uk>, <serge.hallyn@...onical.com>,
	<lucas.demarchi@...fusion.mobi>, <rusty@...tcorp.com.au>,
	<linux-kernel@...r.kernel.org>, <oleg@...hat.com>,
	<linux-fsdevel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	<devel@...nvz.org>
Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

23.05.2013 23:55, J. Bruce Fields пишет:
> On Thu, May 23, 2013 at 09:05:26AM -0400, Jeff Layton wrote:
>> On Thu, 23 May 2013 15:25:20 +0300
>>> I'm not familiar with nfsdcltrack but I would imagine it receives it's information from
>>> Kernel as a command line parameters.
>>>
>>> Would it not be the simplest approach to add a --chroot=/path/to/root optional
>>> parameter to nfsdcltrack so it should access an alternate DB relative to
>>> --chroot.
>>>
>>> This would address Eric's concern of not executing user-privileged executable
>>> from Kernel. I think
>>>
>>> Just my $0.017
>>> Boaz
>>>
>>
>> I think that sounds reasonable. Is it always the case
>> that /path/to/root is reachable from the "primary" namespace?
>
> I don't think we can assume that.
>

Yes, we can't. For example in case of different mount namespaces.

>> If not, you may need to do something more exotic there.
>
> We should be able to pass a file descriptor and then work relative to
> that.
>

We can't do this either.
Moreover, passing a file descriptor is something, that solves (?) completely different problem.
Imagine the following:
1) We have a host, based on, say RHEL6, which nfs-utils has doesn't have "/sbin/nfsdcltrack" and all.
2) And we have a container in it, based on, say, Fedora-19, which nfs-utils has this binary.

In case of starting NFSd in Fedora CT, we won't be able to execute the desired binary without root swapping.
Because we won't be able to even lookup it in the host file system.

So, as I said previously, the main problem here is not how to modify the userspace binary, but how to lookup and execute the right (!) one.
And I don't see, how we can do this (simple enough) without root swap.


-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ