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]

Date:	Mon, 19 Jan 2009 21:04:20 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Ian Kent <raven@...maw.net>,
	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
Subject: Re: [PATCH] autofs: fix the wrong usage of the deprecated
	task_pgrp_nr()

On 01/19, Serge E. Hallyn wrote:
>
> Quoting Oleg Nesterov (oleg@...hat.com):
> > 
> > Actually, I am very much surprized this one-liner patch has so
> > many questions. Isn't it "obiously correct" ?
> 
> I'm not sure which one-liner you're talking about.  In fact,
> the patch I'm looking at right now isn't the one i looked at
> before my last response.  Dangit.
> 
> The patch turning the cached pid_t into a struct pid is
> certainly mostly right.  It shouldn't store a pid_t.

This is the next patch. This one does

	--- CUR/fs/autofs/inode.c~1_AUTOFS	2009-01-12 23:07:46.000000000 +0100
	+++ CUR/fs/autofs/inode.c	2009-01-18 06:18:49.000000000 +0100
	@@ -78,7 +78,7 @@ static int parse_options(char *options, 
	 
		*uid = current_uid();
		*gid = current_gid();
	-	*pgrp = task_pgrp_nr(current);
	+	*pgrp = task_pgrp_vnr(current);
	 
		*minproto = *maxproto = AUTOFS_PROTO_VERSION;

> But as for passing pid_t's in from userspace

passing pid_t's in from userspace uses current namespace, with
or without the patch.

> and especially
> printing them out in error messages, I believe what Ian was
> trying to do before, which seemed sensible, was to always
> use values in the init_pid_ns.  After all, if you do a DPRINTK
> with pid_vnr(somepid), then by the time a human reads the logs
> the subjective pidns might no longer exist.  So for logs I'd
> tend to agree with printing out the pid_t in the init_pid_ns.

OK, may be this makes sense, this was not discussed yet. This
can be changed. But otoh, if this code runs within the sub
namespace, then it is not easy to see why oz_mode == true
if we print the value in init_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/