linux-kernel - Re: CLONE_NEWIPC documentation

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: <m163mji4cz.fsf@frodo.ebiederm.org>
Date:	Wed, 19 Nov 2008 17:16:28 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
Cc:	Kirill Korotaev <dev@...nvz.org>,
	Pavel Emelianov <xemul@...nvz.org>,
	Cedric Le Goater <clg@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>, linux-man@...r.kernel.org
Subject: Re: CLONE_NEWIPC documentation

Michael Kerrisk <mtk.manpages@...glemail.com> writes:

> Kirill, Pavel,
>
> Below is a patch to document the CLONE_NEWIPC flag that was
> added in 2.6.19.
>
> Could you please review and let me know of improvements
> or inaccuracies?
>
> Cheers,
>
> Michael
>
> --- a/man2/clone.2
> +++ b/man2/clone.2
> @@ -225,6 +224,36 @@ Calls to
>  .BR umask (2)
>  performed later by one of the processes do not affect the other process.
>  .TP
> +.BR CLONE_NEWIPC " (since Linux 2.4.19)"
> +If
> +.B CLONE_NEWIPC
> +is set, then create the process in a new IPC namespace.
> +If this flag is not set, then (as with
> +.BR fork (2)),
> +the process is created in the same IPC namespace as
> +the calling process.

> +This flag is intended for the implementation of control groups.

The above sentence is wrong.

+This flag is intended for the implementation of containers.

Would be correct.

Both control groups and namespaces feed into the user space container
concept.  Control groups are multiprocess resource limits.
Namespaces are affect the mapping from resource name to resource.

What is interesting is you can unshare a sysvipc namespace and still have
sysvipc shared memory mapped from another sysvipc namespace.

This is something that needs to be watched for.

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