linux-kernel - Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference

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, 22 Mar 2007 08:28:53 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, Ian Kent <raven@...maw.net>,
	Cedric Le Goater <clg@...ibm.com>, sukadev@...ibm.com,
	Andrew Morton <akpm@...l.org>,
	Dave Hansen <haveblue@...ibm.com>,
	Herbert Poetzl <herbert@...hfloor.at>,
	containers@...ts.osdl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> "Serge E. Hallyn" <serue@...ibm.com> writes:
> >
> > So is the pid used for anything other than debugging?
> >
> > In any case, here is a replacement patch which sends the pid number
> > in the pid_namespace of the process which did the autofs4 mount.
> >
> > Still not sure whether that is actually what makes sense...
> >
> > From: "Serge E. Hallyn" <serue@...ibm.com>
> > Subject: [PATCH] autofs: prevent pid wraparound in waitqs
> >
> > Instead of storing pid numbers for waitqs, store references
> > to struct pids.  Also store a reference to the mounter's pid
> > namespace in the autofs4 sb info so that pid numbers for
> > mount miss and expiry msgs can send the pid# in the mounter's
> > pidns.
> 
> Hmm.  Not quite what I would have expected but given that
> we are sending data over a pipe that sounds reasonable.
> 
> If it wasn't a pipe we would really want to do this in
> the context of the process receiving the message, but since
> a pipe can receive a message, and then be passed to another
> process we clearly can't know the pid namespace of the
> process receiving the message.
> 
> Therefore just caching the pid namespace either on pipe
> open or on mount makes sense.  pipe open might be better.

Right, but the pipe is always opened on mount I think.  (at
autofs4_fill_super)

> Serge we really need to introduce __pid_nr in a separate
> patch.

Agreed.

> And we really seem to be confusing Ian.
> 
> Plus we have some pid namespace ref counting issues we need
> to handle carefully.
> 
> Let's stop working on autofs4 for a bit, fix the pid namespace
> infrastructure so there is enough of it to handle autofs4 and
> then come back.

Agreed.  I just wasn't comfortable stopping until I felt we knew how
autofs4 was going to be addressed.  I think we know now, plus we've
verified another definite need for the __pid_nr(pidns, pid) helper.

> Either that or take autofs4 in two passes.  Pass one we do what
> we can with the current infrastructure.  Pass two after we fix up
> the infrastructure including introducing __pid_nr we come back
> and update autofs4 to handle multiple pid namespaces properly.

Nah, let's hold off, and I'll sit on a patch to send out once rest of
the infrastructure goes in.

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