On 17/12/2007, Steven Rostedt [EMAIL PROTECTED] wrote:
Here's a little snippet of where things went wrong.
[94359.652019] cpu:3 (hackbench:1658) pick_next_task_fair:1036 nr_running=1
[94359.652020] cpu:3 (hackbench:1658) pick_next_entity:625 se=810009020800
[94359.652021] cpu:0
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
A brief description about SYAORAN:
SYAORAN stands for Simple Yet All-important Object Realizing Abiding
Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control.
/dev needs to be writable, but this means that files on /dev might be
[ trimmed the cc' list ]
On 17/12/2007, Steven Rostedt [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007, Dmitry Adamushko wrote:
It may be related, maybe not. One 'abnormal' thing (at least, it
occurs only once in this log. Should be checked wheather it happens
when the system works fine)
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
CAP_MKNOD will be removed from its capability
I think it is not enough because the root can rename/unlink device files
(mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2).
Sure but that doesn't
Eric W. Biederman [EMAIL PROTECTED] wrote:
|
| The following patchset updates the pid namespace infrastructure
| so we don't constantly have to worry if we have been called
| before or after exit_task_namespaces, by using the pid_namespace
| obtained from a processes pid, handles the general case
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside that container ?
Since anyway we will have to keep a white- (or
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
CAP_MKNOD will be removed from its capability
I think it is not enough because the root can rename/unlink device files
(mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1;
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside that container ?
Miklos'
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
But your requirements are to ensure that an application accessing a
device at a well-known location get what it expect.
Yes. That's the purpose of this filesystem.
So then the main quesiton is still the one I
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside
Oleg Nesterov [EMAIL PROTECTED] writes:
On 12/13, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
OK, if we change the semantics for /sbin/init signals we can avoid
a lot of problems,
Yes. Otherwise we must track the source of the signals.
Yes.
Good. We have
11 matches
Mail list logo
