linux-kernel - Re: [RFC PATCH 3/4] kmod - add call_usermodehelper

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, 04 Dec 2014 06:53:46 +0800
From:	Ian Kent <ikent@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Benjamin Coddington <bcodding@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Stanislav Kinsbursky <skinsbursky@...allels.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	David Howells <dhowells@...hat.com>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper

On Wed, 2014-12-03 at 10:49 -0600, Eric W. Biederman wrote:
> 
> >> > Those are the general parameters.
> >> 
> >> It does seem very expensive to keep a thread around for every mount; I'm
> >> still trying to find a way around it..
> >
> > Yeah, that's not such a good idea.
> >
> > Several hundred mounts is going to create a big mess for system
> > administrators, not to mention the overhead. It's right up there with
> > symlinking /etc/mtab to /proc/self/mounts at sites with large direct
> > mount maps.
> 
> A thread will cost you maybe 40k.  In the grand scheme of things that
> really isn't a lot.  I agree that it would be nice to do better than
> one thread per mount.   But I start with a thread as a reference point
> as that is the trivial way to get things correct.

Sure it has merit because it's straight forward but my criticism isn't
about overhead. It's about system administrators annoyance and
frustration level when they're trying get things done.

For example, with the symlinking of the mount table and even just a few
hundred direct automounts, listing the mount table fills the screen with
tombs of stuff that really should be hidden (and only listed if
requested). That just gets in the way when you're trying desperately to
resolve some urgent problem.

There is a resource issue as well since so many site administration
applications will read the table and, as the number of entries gets
larger, so does the time these things take to run. Not having to deal
with this on a day to day basis tends to make us forget about these
little side issues but I think they are important. 

Point is, for process listings the issue is almost exactly the same.

Ian

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