OpenVZ Forum: Devel » [PATCH] IPC namespace

Home » Mailing lists » Devel » [PATCH] IPC namespace

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: [PATCH 2/6] IPC namespace - utils [message #3753 is a reply to message #3743]

Wed, 14 June 2006 11:14

dev
Messages: 1693
Registered: September 2005
Location: Moscow

Senior Member

>>Agreed. Hmm. I bet I didn't see this one earlier because it is specific
>>to the unshare case. In this case I guess we should either deny the unshare
>>or simply undo all of the semaphores. Because we will never be able to
>>talk to them again.
>
> So aren't we reaching the unshare() limits ? Shouldn't we be using the
> exec() principle for the sysvipc namespace ? clear it all and start from
> scratch.
there will be more such issues with more complex namespaces. That's why
I proposed to use containers.
Any way, right now, I don't think this should be urgently fixed as there
are many other ways to crash the node when you are a root.
The rule is simple - the process changing the namespace should be
simple, w/o IPCs. For more complex namespaces (e.g. resource management
namespaces) a fork() can be required after unshare().

>>Thinking about this some more we need to unsharing the semaphore undo semantics
>>when we create a new instances of the sysvipc namespace. Which means that
>>until that piece is implemented we can't unshare the sysvipc namespace.
>
>
> no big issue I think. exit_sem() does it already. it would end up coding
> the yet unsupported unshare_semundo().
do we need really it?
my point is that while with IPCs it maybe quite easy since semundo code
already exists it can be still very hard for other namespaces which do
not track its objects associated with the task.

BTW, do we have the same problem with shm? What will happen if the task
having shm segment will change it's IPC namespace? Besides the possible
crash/stability bugs there can be more interesting effects, for example:
"user will be able to do operations on existing objects with new
namespace limitations?"...

Thanks,
Kirill

Report message to a moderator

[Message index]

		[PATCH] IPC namespace By: Kirill Korotaev on Fri, 09 June 2006 14:55
		[PATCH 1/6] IPC namespace core By: Kirill Korotaev on Fri, 09 June 2006 15:01
		Re: [PATCH 1/6] IPC namespace core By: James Morris on Fri, 09 June 2006 15:26
		Re: [PATCH 1/6] IPC namespace core By: Cedric Le Goater on Fri, 09 June 2006 15:20
		Re: [PATCH 1/6] IPC namespace core By: Andrew Morton on Fri, 09 June 2006 18:38
		Re: [PATCH 1/6] IPC namespace core By: ebiederm on Sat, 10 June 2006 00:44
		Re: [PATCH 1/6] IPC namespace core By: Andrew Morton on Sat, 10 June 2006 03:22
		[PATCH 2/6] IPC namespace - utils By: Kirill Korotaev on Fri, 09 June 2006 15:05
		Re: [PATCH 2/6] IPC namespace - utils By: Cedric Le Goater on Mon, 12 June 2006 17:08
		Re: [PATCH 2/6] IPC namespace - utils By: ebiederm on Mon, 12 June 2006 18:01
		Re: [PATCH 2/6] IPC namespace - utils By: Cedric Le Goater on Mon, 12 June 2006 21:05
		Re: [PATCH 2/6] IPC namespace - utils By: ebiederm on Mon, 12 June 2006 21:49
		Re: [PATCH 2/6] IPC namespace - utils By: Cedric Le Goater on Tue, 13 June 2006 21:17
		Re: [PATCH 2/6] IPC namespace - utils By: dev on Wed, 14 June 2006 11:14
		[PATCH 3/6] IPC namespace - msg By: Kirill Korotaev on Fri, 09 June 2006 15:07
		[PATCH 4/6] IPC namespace - sem By: Kirill Korotaev on Fri, 09 June 2006 15:08
		[PATCH 5/6] IPC namespace - shm By: Kirill Korotaev on Fri, 09 June 2006 15:09
		[PATCH 6/6] IPC namespace - sysctls By: Kirill Korotaev on Fri, 09 June 2006 15:11
		Re: [PATCH] IPC namespace By: Dave Hansen on Mon, 12 June 2006 17:19
		Re: [PATCH] IPC namespace By: ebiederm on Tue, 13 June 2006 02:44
		Re: [PATCH] IPC namespace By: dev on Tue, 13 June 2006 16:41
		Re: [PATCH] IPC namespace By: ebiederm on Tue, 13 June 2006 17:01

Previous Topic:	[PATCH 2.6.17-rc6-mm2] ipc namespace : unshare fix
Next Topic:	Re: Linux-VServer and OpenVZ for Debian

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Nov 30 13:04:49 GMT 2025

Total time taken to generate the page: 0.80797 seconds