linux-kernel - Re: [RFC] dealing with proc_ns_follow

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:	Sat, 1 Nov 2014 22:04:58 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Eric W.Biederman" <ebiederm@...ssion.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] dealing with proc_ns_follow_link() and "namespace" dentries

On Sat, Nov 01, 2014 at 06:38:02PM +0000, Al Viro wrote:
> On Sat, Nov 01, 2014 at 11:23:34AM -0700, Eric W.Biederman wrote:
> 
> > >From your description I am concerned about using the letter combination nsfs.   I once used nsfd, and that was so close to nfsd that Linus got confused, and hilarity ensued.   nsfs isn't quite as bad but the abbreviation still seems close enough to nfs that confusion could result.
> 
> Well, yes, but... the only non-static object in there with "nsfs" in the
> name is nsfs_init().  As for the filename itself... any better suggestions
> would be welcome, but it doesn't really mess the completion tree.
> 
> I've no strong preferences here - we might even move it into kernel/nsproxy.c.
> In the latest variant it's ~160 lines...

BTW, as an immediate followup, definition of struct nameidata can be
taken to fs/namei.c now.  nd_get_link/nd_set_link become exported, actual
declaration of struct nameidata goes into fs/namei.c and for everything
outside of fs/namei.c it becomes completely opaque.

TBH, I'm somewhat tempted to do something even more extreme - try to treat
it the way we treat pt_regs.  I.e. have a pointer to such sucker in
task_struct (NULL most of the time) and chain the instances.  That way
we'd be rid of passing that sucker even to ->follow_link() (and to
nd_{set,get}_link() as well).  path_init() would push the sucker to the
top of the chain, path_finish(nd, base) (currently open-coded bunch of
        if (nd->root.mnt && !(nd->flags & LOOKUP_ROOT))
                path_put(&nd->root);
	if (base)
		fput(base);
) - remove it from the chain.  Not sure if it's worth doing - it's slightly
less boilerplate in ->follow_link() and ->put_link() instances and it _might_
reduce the stack footprint in a bunch of places in fs/namei.c (including the
recursion in there), but it might easily end up increasing it instead...
--
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/