[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 03 Mar 2009 17:17:35 +0100
From: Cedric Le Goater <legoater@...e.fr>
To: Alexey Dobriyan <adobriyan@...il.com>
CC: "Serge E. Hallyn" <serue@...ibm.com>, linux-api@...r.kernel.org,
containers@...ts.linux-foundation.org, mpm@...enic.com,
linux-kernel@...r.kernel.org,
Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org,
tglx@...utronix.de, viro@...iv.linux.org.uk, hpa@...or.com,
Ingo Molnar <mingo@...e.hu>, torvalds@...ux-foundation.org,
Andrew Morton <akpm@...ux-foundation.org>, xemul@...nvz.org
Subject: Re: How much of a mess does OpenVZ make? ;) Was: What can OpenVZ
do?
>> 1. cap_sys_admin check is unfortunate. In discussions about Oren's
>> patchset we've agreed that not having that check from the outset forces
>> us to consider security with each new patch and feature, which is a good
>> thing.
>
> Removing CAP_SYS_ADMIN on restore?
we've kept the capabilities in our patchset but the user tools doing checkpoint
and restart are setcap'ed appropriately to be able to do different things like :
clone() the namespaces
mount /dev/mqueue
interact with net_ns
etc.
at restart, the task are restarted through execve() so they loose their
capabilities automatically.
but I think we could drop the CAP_SYS_ADMIN tests for some namespaces,
uts and ipc are good candidates. I guess network should require some
privilege.
C.
--
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