Hi Serge,
(Thanks for looking at this. I appreciate the review!)
On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
> > struct vfsmount *mnt = nd->mnt;
> > - struct dentry *dentry = __d_lookup(nd->dentry, name);
> > + struct dentry *dentry;
> >
> > +again:
> > + dentry = __d_lookup(nd->de
Hello.
Serge E. Hallyn wrote:
> Nope, try
>
> touch /root/hda1
> ls -l /root/hda1
> mount --bind /dev/hda1 /root/hda1
> ls -l /root/hda1
[EMAIL PROTECTED] ~]# touch /root/hda1
[EMAIL PROTECTED] ~]# ls -l /root/hda1
-rw-r--r-- 1 root root 0 Dec 18 12:04 /root/hda1
[EMAIL PROTECTED] ~]# mo
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 i
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 stil
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 think Al had asked - what
> keeps a rogue CAP_SYS_
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 ?
Mik
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 black-)
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/sd
On Mon, Dec 17, 2007 at 06:03:38PM +0300, Evgeniy Polyakov wrote:
> DST passed all FS tests in LTP with XFS (modulo MAX_LOCK_DEPTH too low bug:
> [ 8398.605691] BUG: MAX_LOCK_DEPTH too low!
> [ 8398.609641] turning off the locking correctness validator.
Evgeniy, can you please start reporting thes
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'
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).
> To use your approach, i guess we would have to use selinux (or tomoyo)
>
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> The revoke operation cannibalizes the revoked struct inode and removes it from
> the inode cache thus forcing subsequent callers to look up the real inode.
> Therefore we must make sure that while the revoke o
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 mi
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
include/linux/chio.h|2 +-
include/linux/cyclades.h|2 +-
include/linux/cycx_x25.h|2 +-
include/linux/dmaengine.h |2 +-
include/linux/ethtool.h |2 +-
include/linux/fs.h
On Dec 17, 2007 4:03 PM, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> +++ b/Documentation/dst/sysfs.txt
> @@ -0,0 +1,33 @@
> +This file describes sysfs files created for each storage.
> +
> +1. Per-storage files.
> +Each storage has its own dir /sysfs/devices/$storage_name,
> +2. Per-node files.
Algorithms used in distributed storage.
Mirror and linear mapping code.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/drivers/block/dst/alg_linear.c b/drivers/block/dst/alg_linear.c
new file mode 100644
index 000..836764d
--- /dev/null
+++ b/drivers/block/dst/alg_linear.c
Network state machine.
Includes network async processing state machine and related tasks.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/drivers/block/dst/kst.c b/drivers/block/dst/kst.c
new file mode 100644
index 000..6d92014
--- /dev/null
+++ b/drivers/block/dst/kst.c
@
Distributed storage documentation.
Algorithms used in the system, userspace interfaces
(sysfs dirs and files), design and implementation details
are described here.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/Documentation/dst/algorithms.txt b/Documentation/dst/algorithms.
Core distributed storage files.
Include userspace interfaces, initialization,
block layer bindings and other core functionality.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index b4c8319..ca6592d 100644
--- a/drivers/block/Kconf
Distributed storage.
I'm pleased to announce the 12'th release of the distributed
storage subsystem (DST).
DST allows to form a storage on top of local and remote nodes
and combine them into linear or mirroring setup, which in
turn can be exported to remote nodes.
Short changelog:
* new improv
( This is a reply to http://lkml.org/lkml/2007/12/17/27 .)
Hello.
David Wagner wrote:
> But the point is that it's not enough just to prevent attackers
> from mounting other filesystems over this filesystem. I can think
> of all sorts of ways that an admin-level attacker might be able to
> preve
Hello.
Al Boldi wrote:
> I think the answer is obvious: Tetsuo wants to add functionality that the
> MACs are missing. So, instead of adding this functionality per MAC, he
> proposes to add it as ground work, to be combined with any MAC.
Yes, that's right.
This filesystem is designed to be used
Hello.
Indan Zupancic wrote:
> If MAC can avoid all that, then why can't it also avoid tampering with /dev?
If MAC implementation handles filename and its attributes pair, this filesystem
is not needed.
But I don't know MAC implementations that handle this pair.
SELinux's granularity is "allow
Hi,
On Mon, December 17, 2007 01:40, Tetsuo Handa wrote:
> Hello.
>
> Indan Zupancic wrote:
>> What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
> Mandatory access control (MAC) prevents them from mounting tmpfs on top of
> /dev .
> MAC mediates namespace manipulation reque
24 matches
Mail list logo
