netdev - Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time

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:	Thu, 30 Dec 2010 13:45:14 +0200
From:	"Kirill A. Shutemov" <kas@...nvz.org>
To:	Rob Landley <rob@...dley.net>
Cc:	"Kirill A. Shutemov" <kas@...nvz.org>,
	Rob Landley <rlandley@...allels.com>,
	Trond Myklebust <Trond.Myklebust@...app.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Neil Brown <neilb@...e.de>,
	Pavel Emelyanov <xemul@...allels.com>,
	linux-nfs@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time

On Thu, Dec 30, 2010 at 05:05:22AM -0600, Rob Landley wrote:
> On Thu, Dec 30, 2010 at 4:44 AM, Kirill A. Shutemov <kas@...nvz.org> wrote:
> > On Thu, Dec 30, 2010 at 04:05:07AM -0600, Rob Landley wrote:
> >> On 12/30/2010 03:44 AM, Kirill A. Shutemov wrote:
> >> >>> If no rpcmount mountoption, no rpc_pipefs was found at
> >> >>> '/var/lib/nfs/rpc_pipefs' and we are in init's mount namespace, we use
> >> >>> init_rpc_pipefs.
> >> >>
> >> >> It's the "we are in init's mount namespace" that I was wondering about.
> >> >>
> >> >> So if I naievely chroot, nfs mount stops working the way it did before I
> >> >> chrooted unless I do an extra setup step?
> >> >
> >> > No. It will work as before since you are still in init's mount namespace.
> >> > Creating new mount namespace changes rules.
> >>
> >> Ah, CLONE_NEWNS and then you need /var/lib/nfs/rpc_pipefs.  Got it.
> >>
> >> I'm kind of surprised that the kernel cares about a specific path under
> >> /var/lib.  (Seems like policy in the kernel somehow.)
> >
> > Yep. It's bad, but there is way to overwrite the default.
> >
> > Other way is to leave 'rpcmount' mountoption without default.
> > get_rpc_pipefs(NULL) in init's mount namespace will always return
> > init_rpc_pipefs, without filesystem lookup.
> > get_rpc_pipefs(NULL) in non-init's mount namespace will always return
> > error.
> >
> > So you will have to specify 'rpcmount' mountoption for every nfs mount in
> > container. Hmm, I guess, it may confuse user.
> >
> > Or we can try to move the default to userspace. /sbin/mount.nfs?
> 
> /proc/sys/kernel/hotplug exists to tell the kernel where to find the hotplug
> binary.  Once upon a time /sys/hotplug was the default value, and that was
> there to overwrite it.  (They changed the default to blank (disabled) not due
> to policy reasons, but due to adding the netlink hotplug notification
> mechanism and making that the default.)
> 
> I bring that up to point out that the general consensus about policy in the
> kernel seems to be "when you really really can't avoid having any, make a
> sane default the user can override".
> 
> (Of course adding another entry to the crawling horror of /proc may not
> be an improvement.  But individual overrides at the mount -o level seem
> like a non-optimal granularity for this...)

Do you propose to implement default as sysctl parameter?

> >> Can't it just
> >> check the current process's mount list to see if an instance of
> >> rpc_pipefs is mounted in the current namespace the way lxc looks for
> >> cgroups?  Or are there potential performance/scalability issues with that?
> >
> > What should we do if we have several rpc_pipefs mounts in the namespace?
> 
> You mean more than one inside a given process's view of the filesystem, taking
> into account chroot like /proc/mounts does?
> 
> Before this patch series, there was one instance systemwide.  The patch changed
> that to look a fixed location in the filesystem relative to the
> current chroot.  Either
> way, there was one instance available to a given process doing an nfs mount.
> 
> What's the use case for having more than one visible to a given process?
> (NUMA scalability?  Some sort of multipath/VPN routing context?)

It's no so obvious for me why we should restrict it. ;)

Currently, there is no association between rpc_pipefs and mount namespace,
so I don't see simple way to restrict number of rpc_pipefs per mount
namespace. Associating mount namespace with rpc_pipefs is not a good idea,
I think.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html