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:	Sun, 14 Aug 2011 18:01:12 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Daniel Lezcano <daniel.lezcano@...e.fr>
Cc:	akpm@...ux-foundation.org, bonbons@...ux-vserver.org,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, serge@...lyn.com
Subject: Re: [PATCH 2/2] Notify container-init parent a 'reboot' occured

On 08/11, Daniel Lezcano wrote:
>
> When the reboot syscall is called and the pid namespace where the calling
> process belongs to is not from the init pidns, we send a SIGCHLD with CLD_REBOOTED
> to the parent of this pid namespace.

OK, but why you can't simply send the signal?

Why do you need the strange do_notify_parent_cldreboot() which tries
to mimic do_notify_parent() for (afaics) no reason ?

> +void do_notify_parent_cldreboot(struct task_struct *tsk, int why, char *buffer)

buffer is not used. Why?

> +	if (tsk->ptrace)
> +		parent = tsk->parent;
> +	else {
> +		tsk = tsk->group_leader;
> +		parent = tsk->real_parent;
> +	}

For what? I simply can't understand this...

> +     sighand = parent->sighand;
> +     spin_lock_irqsave(&sighand->siglock, flags);

this is unsafe, we can't trust ->sighand and parent.

> +	 * Even if SIGCHLD is not generated, we must wake up wait4 calls.

but not in this case, afaics?

> +	__wake_up_parent(tsk, parent);

Why do you need __wake_up_parent()?

> +static void pid_namespace_reboot(struct pid_namespace *pid_ns,
> +				int cmd, char *buffer)
> +{
> +	struct task_struct *tsk = pid_ns->child_reaper;
> +	do_notify_parent_cldreboot(tsk, cmd, buffer);

nothing prevents ->child_reaper from exiting it it is multithreaded,
this can crash the kernel.

> @@ -426,10 +434,18 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
>  {
>  	char buffer[256];

again, it is not used.

>  	int ret = 0;
> +	struct pid_namespace *pid_ns = current->nsproxy->pid_ns;
> +
> +        /* We only trust the superuser with rebooting the system. */
> +	if (!capable(CAP_SYS_BOOT)) {
> +		/* If we are not in the initial pid namespace, we send a signal
> +		 * to the parent of this init pid namespace, notifying a shutdown
> +		 * occured */
> +		if (pid_ns != &init_pid_ns)
> +			pid_namespace_reboot(pid_ns, cmd, buffer);

Hmm. Looks like pid_ns should be checked after CAP_SYS_BOOT?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ