linux-kernel - Re: [PATCH] autofs: fix the wrong usage of the deprecated task_pgrp

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]

Message-ID: <20090119143046.GA8284@redhat.com>
Date:	Mon, 19 Jan 2009 15:30:46 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Ian Kent <raven@...maw.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
	Pavel Emelyanov <xemul@...nvz.org>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, "SergeE.Hallyn" <serue@...ibm.com>
Subject: Re: [PATCH] autofs: fix the wrong usage of the deprecated
	task_pgrp_nr()

On 01/19, Ian Kent wrote:
>
> On Mon, 2009-01-19 at 13:42 +0100, Oleg Nesterov wrote:
> >
> > Before the patch
> >
> > 	sbi->oz_pgrp != task_pgrp(automount)
> >
> > After the patch
> >
> > 	sbi->oz_pgrp == task_pgrp(automount)
> >
> > And please note that these "!="/"==" apply to any namespace. I mean,
> > when we call autofs_oz_mode() it does not matter in which namespace
> > autofs_oz_mode() is executed, we compare "struct pid*", not pid_t.
>
> I think your saying that the option pgrp= is broken and should be
> deprecated

No, no, sorry if I confused you.

If the "pgrp=" option was specified, the patch has no effect, and the
code is correct with or without the patch.

> It's interesting that your description appears to assume the the same
> process may appear in different pid namespaces (am I right?)

Yes. It is visible in its own namespace, in the ->parent namespace,
->parent->parent, and so on until the global init_pid_ns.

> whereas in
> the descriptions I have been writing I'm thinking of pid namspeces as
> having there own set of proceses and not being able to see processes
> outside the space.

Yes, we can not see the tasks outside the space (but of course we can
see the tasks from the child namespaces).

IOW. Let's suppose we are in the global namespace, and some task
forks the child C via clone(CLONE_NEWPID).

Now, in the global namespace it has, say, pid == 100. But when
C does sys_getpid() it gets 1.

C can not see the tasks from the global namespace, but any task
from the global ns can see C with pid == 100.

And please note that C has the single "struct pid" wchich represents
all pid_t's. The same for pgrp/session. task_pgrp() returns the same
pid (pointer to the struct, not pid_t), no matter in which namespace
the code runs. But the result of pid_vnr(pid) or find_pid(pid_nr) do
differ depending on current->nsproxy->pid_ns.

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/