From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [RFC][PATCH] Devices visibility container Date: Tue, 25 Sep 2007 11:48:03 +0400 Message-ID: <46F8BD33.5040108@openvz.org> References: <46F77523.9020001@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: Linux Containers , Paul Menage List-Id: containers.vger.kernel.org Eric W. Biederman wrote: > Pavel Emelyanov writes: > >> Hi. >> >> At KS we have pointed out the need in some container, that allows >> to limit the visibility of some devices to task within it. I.e. >> allow for /dev/null, /dev/zero etc, but disable (by default) some >> IDE devices or SCSI discs and so on. > > NAK > > We do not want a control group subsystem for this. > > For the short term we can just drop CAP_SYS_MKNOD. > > For the long term we need a device namespace for application > migration, so they can continue to use devices with the same > major+minor number pair after the migration event. Things like Oh! Can you provide us an example when after the migration some device's major+minor pair change on the same device? > ensuring a call to stat on a given file before and after the migration > return the exact same information sounds compelling. So I don't think > this is even strictly limited to virtual devices anymore. How many > applications are there out there that memorize the stat data on a file > and so they can detect if it has changed? > > If we need something between those two it may make sense to enhance > the LSM or perhaps introduce an alternate set security hooks. Still > if we are going to need a full device namespace that may be a little > much. > > Eric >