It's nice to check for consistency though, so we're adding that. Profile
loading is a trusted operation, at least so far, and so security wise we
don't actually have to care --- if loading an invalid profile can bring down
the system, then that's no worse than an arbitrary module that
Hi Andreas,
--On 12 April 2007 5:05:50 AM -0600 Andreas Dilger [EMAIL PROTECTED] wrote:
I'm interested in getting input for implementing an ioctl to efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a billion
times.
...
I had come up with a plan independently and
On Fri, 2007-04-13 at 13:58 +0200, Miklos Szeredi wrote:
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
On Fri, 2007-04-13 at 16:05 +0200, Miklos Szeredi wrote:
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
unshare(2), then allow user mounts within the new namespace.
This is not flexible
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user into /share/$USER will actually
_grant_ a
On Mon, 2007-04-16 at 11:32 +0200, Miklos Szeredi wrote:
Given the existence of shared subtrees allowing/denying this at the
mount
namespace level is silly and wrong.
If we need more than just the filesystem permission checks can we
make it a mount flag settable with mount and
From: Miklos Szeredi [EMAIL PROTECTED]
Add ownership information to mounts.
A new mount flag, MS_SETUSER is used to make a mount owned by a user.
If this flag is specified, then the owner will be set to the current
real user id and the mount will be marked with the MNT_USER flag. On
remount
From: Miklos Szeredi [EMAIL PROTECTED]
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having user=UID option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to exclude another mount on the same mountpoint.
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting the permit user submount
mount flag will also be needed.
From: Miklos Szeredi [EMAIL PROTECTED]
Declarations go into headers.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/super.c
===
--- linux.orig/fs/super.c 2007-04-13 12:26:11.0 +0200
+++
From: Miklos Szeredi [EMAIL PROTECTED]
Allow clone_mnt() to return errors other than ENOMEM. This will be
used for returning a different error value when the number of user
mounts goes over the limit.
Fix copy_tree() to return EPERM for unbindable mounts.
Don't propagate further from
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
unprivileged mounts will be denied.
By default this flag is cleared, and can be set on new mounts, on
remounts or with the MS_SETFLAGS option.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
On Thu, Apr 12, 2007 at 05:05:50AM -0600, Andreas Dilger wrote:
I'm interested in getting input for implementing an ioctl to efficiently
map file extents holes (FIEMAP) instead of looping over FIBMAP a billion
times. We already have customers with single files in the 10TB range and
we
Hi Al,
I think there might be a problem in the VFS with d_revalidate() not being
called enough on mountpoints. As far as I can tell from the printks in my AFS
stuff, it's only called on the mounted-on dentry, and not the vfsmount-root
dentry. However, with NFS at least (not so much AFS), can
On Mon, 2007-04-16 at 13:50 +0100, David Howells wrote:
Hi Al,
I think there might be a problem in the VFS with d_revalidate() not being
called enough on mountpoints. As far as I can tell from the printks in my AFS
stuff, it's only called on the mounted-on dentry, and not the vfsmount-root
Miklos Szeredi [EMAIL PROTECTED] writes:
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user
Miklos Szeredi [EMAIL PROTECTED] writes:
That depends. Current patches check the unprivileged submounts
allowed under this mount flag only on the requested mount and not on
the propagated mounts. Do you see a problem with this?
I think privileges of this sort should propagate. If I read
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user into /share/$USER will actually
On Thursday 12 April 2007 12:06, Christoph Hellwig wrote:
Once again very strong NACK. Every conditional passing of vfsmounts get my
veto. As mentioned last time if you really want this send a patch series
first that passed the vfsmount consistantly.
I don't consider it fair to NACK this
On Mon, Apr 16, 2007 at 06:11:30PM +0200, Andreas Gruenbacher wrote:
+static inline int
+nfsd_do_create(struct inode *dir, struct dentry *child, struct vfsmount *mnt,
+int mode)
+{
+ struct nameidata nd = {
+ .dentry = child,
+ .mnt = mnt,
+ };
Here is a patch with request for comment.
The create, lookup, and permission inode operations are all passed a full
nameidata. This is unfortunate because in nfsd and the mqueue filesystem we
must instantiate a struct nameidata, but cannot provide all of the same
information of a regular lookup.
On Mon, Apr 16, 2007 at 06:29:20PM +0200, Andreas Gruenbacher wrote:
enum { MAX_NESTED_LINKS = 8 };
+/**
+ * Fields shared between nameidata and nameidata2 -- nameidata2 could
+ * be embedded in nameidata, but then the vfs code would become
+ * cluttered with dereferences.
you could use
On Monday 16 April 2007 18:21, Christoph Hellwig wrote:
But anyway, creating fake nameidata structures is not really helpful.
If there is a nameidata passed people expect it to be complete, and
if you pass them to an LSM people will e.g. try to look into lookup
intents.
I don't actually agree
On Mon, 16 Apr 2007 18:29:20 +0200 Andreas Gruenbacher wrote:
Here is a patch with request for comment.
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -14,21 +14,39 @@ struct open_intent {
enum { MAX_NESTED_LINKS = 8 };
+/**
Please don't use the kernel-doc begin-marker
On Monday 16 April 2007 18:42, Randy Dunlap wrote:
Please don't use the kernel-doc begin-marker /** when the comment block
isn't in kernel-doc format.
Sigh, kernel-doc should improve things, not get in the way ...
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the
On Mon, Apr 16, 2007 at 06:40:41PM +0200, Andreas Gruenbacher wrote:
On Monday 16 April 2007 18:21, Christoph Hellwig wrote:
But anyway, creating fake nameidata structures is not really helpful.
If there is a nameidata passed people expect it to be complete, and
if you pass them to an LSM
Andreas Gruenbacher wrote:
On Monday 16 April 2007 18:42, Randy Dunlap wrote:
Please don't use the kernel-doc begin-marker /** when the comment block
isn't in kernel-doc format.
Sigh, kernel-doc should improve things, not get in the way ...
Well, I see it as sort of a language that is
On Mon, 2007-04-16 at 11:56 +0200, Miklos Szeredi wrote:
Also for bind-mount and remount operations the flag has to be propagated
down its propagation tree. Otherwise a unpriviledged mount in a shared
mount wont get reflected in its peers and slaves, leading to unidentical
On Mon, 2007-04-16 at 12:34 +0200, Miklos Szeredi wrote:
Currently one of the difficulties with mount propagations is that
there's no way to know the current state of the propagation tree.
Has anyone thought about how this info could be queried from
userspace?
I am attaching two patches
Also for bind-mount and remount operations the flag has to be
propagated
down its propagation tree. Otherwise a unpriviledged mount in a
shared
mount wont get reflected in its peers and slaves, leading to
unidentical
shared-subtrees.
That's an
Miklos Szeredi [EMAIL PROTECTED] writes:
That depends. Current patches check the unprivileged submounts
allowed under this mount flag only on the requested mount and not on
the propagated mounts. Do you see a problem with this?
I think privileges of this sort should propagate. If I
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
-serge
unprivileged mounts will
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having user=UID option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Miklos Szeredi [EMAIL PROTECTED] writes:
That depends. Current patches check the unprivileged submounts
allowed under this mount flag only on the requested mount and not on
the propagated mounts. Do you see a problem with this?
I
On Mon, Apr 16, 2007 at 01:39:19PM -0600, Eric W. Biederman wrote:
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having user=UID option in
On Mon, Apr 16, 2007 at 08:27:08AM +0200, Andi Kleen wrote:
It's nice to check for consistency though, so we're adding that. Profile
loading is a trusted operation, at least so far, and so security wise we
don't actually have to care --- if loading an invalid profile can bring
down
On Mon, Apr 16, 2007 at 10:39:46AM -0700, Ram Pai wrote:
This patch disambiguates multiple mount-instances of the same
filesystem (or part of the same filesystem), by introducing a new
interface /proc/mounts_new. The interface has the following format.
^^
... odd name.
Here we present our direct responses to the most frequent questions from
the AppArmor from the 2006 post.
Use of Pathnames For Access Control
---
Some people in the security field believe that pathnames are an
inappropriate security mechanism. This depends on
On Thu, Apr 12, 2007 at 11:21:01AM +0100, Alan Cox wrote:
+
+ /**
+* parent can ptrace child when
+* - parent is unconfined
+* - parent is in complain mode
+* - parent and child are confined by the same profile
+*/
Your profiles are name based. That means the
That is a fairly significant and sudden change to the existing
kernel/user interface.
Well, this is not meant for 2.6.21. I hope it is possible to change it in
early 2.6.22; otherwise if we can't fix mistakes from the past we are pretty
doomed.
I don't believe the existing behaviour
don't actually have to care --- if loading an invalid profile can bring down
the system, then that's no worse than an arbitrary module that crashes the
machine. Not sure if there will ever be user loadable profiles; at least at
that point we had to care.
CAP_SYS_RAWIO is needed to do
On Mon, Apr 16, 2007 at 11:00:01PM +0100, Alan Cox wrote:
don't actually have to care --- if loading an invalid profile can bring
down
the system, then that's no worse than an arbitrary module that crashes the
machine. Not sure if there will ever be user loadable profiles; at least at
On Thu, Apr 12, 2007 at 06:48:52AM +0200, Nick Piggin wrote:
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
2.6.21-rc6-new-aops*
New aops patchset against 2.6.21-rc6.
Ok, here's an ocfs2 patch against -mm / ocfs2.git ALL. It makes use of the
context back pointer to
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to the data. As the data flows
through the system, the label sticks to the data, and so security
policy with respect to this data stays intact.
On Mon, Apr 16, 2007 at 05:19:32PM -0700, Mark Fasheh wrote:
On Thu, Apr 12, 2007 at 06:48:52AM +0200, Nick Piggin wrote:
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
2.6.21-rc6-new-aops*
New aops patchset against 2.6.21-rc6.
Ok, here's an ocfs2 patch
46 matches
Mail list logo
