linux-kernel - Re: [PATCH] user namespace: usb: make usb urbs user namespace aware

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: <20110920131738.GA29852@redhat.com>
Date:	Tue, 20 Sep 2011 15:17:38 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, richard@....at,
	Andrew Morton <akpm@...gle.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tejun Heo <tj@...nel.org>, serge@...lyn.com
Subject: Re: [PATCH] user namespace: usb: make usb urbs user namespace aware

On 09/19, Serge E. Hallyn wrote:
>
> Add to the dev_state and alloc_async structures the user namespace
> corresponding to the uid and euid.  Pass these to kill_pid_info_as_uid(),
> which can then implement a proper, user-namespace-aware uid check.

IOW, we add the additional "user_namespace *" member/argument, and use
it along with uid/euid.

I am not really sure, but can't we simplify this?

> @@ -68,6 +69,7 @@ struct dev_state {
>  	wait_queue_head_t wait;     /* wake up if a request completed */
>  	unsigned int discsignr;
>  	struct pid *disc_pid;
> +	struct user_namespace *user_ns;
>  	uid_t disc_uid, disc_euid;

Can't we add "const struct cred *disc_cred" and kill disc_uid/disc_euid
instead?

Then we redefine kill_pid_info_as_uid() as kill_pid_info_as_cred(...cred...),
it can use cred->cred->uid/euid directly.

devio.c does get_cred/put_cred instead of get_user_ns/put_user_ns.

What do you think?

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/