linux-kernel - Re: [PATCH] autofs4: turn ->oz

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] [day] [month] [year] [list]

Date:	Fri, 23 Jan 2009 12:51:32 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Ian Kent <raven@...maw.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
	Cedric Le Goater <clg@...ibm.com>,
	Dave Hansen <haveblue@...ibm.com>,
	Eric Biederman <ebiederm@...ssion.com>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Serge Hallyn <serue@...ibm.com>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] autofs4: turn ->oz_pgrp into "struct pid *"

On 01/23, Ian Kent wrote:
>
> On Fri, 2009-01-23 at 09:06 +0100, Oleg Nesterov wrote:
> > On 01/23, Ian Kent wrote:
> > >
> > > On Sun, 2009-01-18 at 08:34 +0100, Oleg Nesterov wrote:
> > > >
> > > > I guess autofs4_show_options()->pid_vnr() is not exactly right, but hopefully
> > > > not worse than the current code.
> > >
> > > But shouldn't pid_vnr(sbi->oz_pgrp) report the pid as seen in the
> > > namespace of the calling process? In which case the only problem would
> > > be listing the mount table from a subordinate namespace that cannot see
> > > the process which did the mount, assuming fs namespace is not linked in
> > > some strict way to pid namespace, this could give an odd result. What
> > > might happen in this case Oleg?
> > 
> > Yes, nothing bad can happen. pid_vnr() just returns 0 if the calling
> > process can't see the namespace.
> > 
> > But I was worried about the case when, say, we are looking at
> > /subnamespace_root_mount/proc/mounts.
> > 
> > In that case pid_vnr() will report the pid_t in the global namespace,
> > this differs from the case when this file is read by its own namespace
> > as /proc/mounts.
> > 
> > I do not know whether this is right or not, though.
> 
> Right, but mostly a source of confusion than anything else as things
> will still function OK. Not sure how to deal with that!

Yes. But just in case, please note that the current code is just
wrong in this respect, it always reports the "global" pid_t which
doesn't make sense for the sub-namespace.

Oleg.

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