Quoting David Howells ([EMAIL PROTECTED]):
>
>
> These patches add local caching for network filesystems such as NFS.
>
> The patches can roughly be broken down into a number of sets:
>
> (*) 01-keys-inc-payload.diff
> (*) 02-keys-search-keyring.diff
> (*) 03-keys-callout-blob.diff
>
>
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > > > think that would make a lot of sense anyway.
> > > >
> > > > Would it be as simple as tagging the inodes with capability sets? One
> > > > set for writing, or one eac
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > think that would make a lot of sense anyway.
> >
> > Would it be as simple as tagging the inodes with capability sets? One
> > set for writing, or one each for reading and wr
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > + t->table[0].mode = 0644;
> >
> > Yikes, this could be a problem for containers, as it's simply tied to
> > uid 0, whereas tying it to a capability would let us solve it with
> > capability bounds.
> >
> > This might mean more urgency to get user
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
> Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Thanks, Miklos, good explanations in the docs.
Acked-by: Serge Hallyn <[EMAIL P
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > What do you think about doing this only if FS_SAFE is also set,
> > > > so for instance at first only FUSE would allow itself to be
> > > > made user-mountable?
> > > >
> > > > A safe thing to do, or overly intrusive?
> > >
> > > It goes somewha
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
> > > > You have removed the code that checked if the peer or
> > > > master mount was in the same namespace before reporting their
> > > > corresponding mount-ids. One d
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > What do you think about doing this only if FS_SAFE is also set,
> > so for instance at first only FUSE would allow itself to be
> > made user-mountable?
> >
> > A safe thing to do, or overly intrusive?
>
> It goes somewhat against the "no policy in
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
> Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
> ---
>
> Index: linux/fs/filesystems.c
> ==
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> On mount propagation, let the owner of the clone be inherited from the
> parent into which it has been propagated.
>
> If the parent has the "nosuid" flag, set this flag for the child as
> well. This is ne
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Don't require the "user_id=" and "group_id=" options for unprivileged mounts,
> but if they are present, verify them for sanity.
>
> Disallow the "allow_other" option for unprivileged mounts.
>
> FUSE was
Quoting Kentaro Takeda ([EMAIL PROTECTED]):
> Hello.
>
> Serge E. Hallyn wrote:
> > I must say I personally prefer the apparmor approach.
> No problem.
>
> > But I'd recommend
> > you get together and get this piece pushed on its own, whichever version
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > On mount propagation, let the owner of the clone be inherited from the
> > > > > parent into which it has been propagated. Also if the parent has the
> > > > > "nosuid" flag, set this flag for the child as well.
> > > >
> > > > What about node
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > >
> > > On mount propagation, let the owner of the clone be inherited from the
> > > parent into which it has been propagated. Also if the parent has the
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Why not "nosubmnt"?
>
> Why not indeed. Maybe I should try to use my brain sometime.
Well it really should have 'user' or 'unpriv' in the name
somewhere. 'nosubmnt' is more confusing than 'nomnt' because
it no submounts really sounds like a reason
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Sounds like a sysctl to enable FS_SAFE for fuse will make this patch
> > acceptable to everyone?
>
> I think the most generic approach, is to be able to set "safeness" for
> any fs type, not just fuse (Karel's suggestion).
>
> E.g:
>
> echo 1 > /
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add a new mount flag "nomnt", which denies submounts for the owner.
> This would be useful, if we want to support traditional /etc/fstab
> based user mounts.
>
> In this case mount(8) would still have to be
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged users. This
> has also been verified in practice over many years. In addition un
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> On mount propagation, let the owner of the clone be inherited from the
> parent into which it has been propagated. Also if the parent has the
> "nosuid" flag, set this flag for the child as well.
What abou
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of
> this filesystem may not constitute a security problem.
>
> Since most filesystems haven't been designed with unprivileged mountin
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Allow bind mounts to unprivileged users if the following conditions are met:
>
> - mountpoint is not a symlink
> - parent mount is owned by the user
> - the number of user mounts is below the maximum
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> 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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> 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 a mount to
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> 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, pres
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patchset adds support for keeping mount ownership information in the
> kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
>
> The mount owner has the following privileges:
>
> -
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Allow bind mounts to unprivileged users if the following conditions are met:
>
> - mountpoint is not a symlink
> - parent mount is owned by the user
> - the number of user mounts is below the maximum
Quoting Indan Zupancic ([EMAIL PROTECTED]):
> Hello,
>
> On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
> > Hello.
> >
> > Indan Zupancic wrote:
> >> I think you focus too much on your way of enforcing filename/attributes
> >> pairs.
> > So?
>
> So that you miss alternatives and don't see the
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
> Hello.
>
> Thank you for attending discussion for previous posting
> (starting from http://lkml.org/lkml/2007/12/16/23 ).
>
> The previous posting was for feasibility test to know
> whether this kind of trivial filesystem is acceptable for mainline.
>
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> fcntl(F_GETLK,..) can return pid of process for not current pid namespace (if
> process is belonged to the several namespaces). It is true also for pids
> in /proc/locks. So correct behavior is saving pointer to the struct pid of
> the process lock ow
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> Oren Laadan wrote:
> >
> > Serge E. Hallyn wrote:
> >> Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> >>> Oren Laadan wrote:
> >>>> Serge E. Hallyn wrote:
> >>>>> Quoting Oren Laad
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.
I apologize if I'm commiting a faux pas by asking this, but any chan
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
> Hi,
>
> On Wed, 19 Dec 2007, Serge E. Hallyn wrote:
> > > I assume you mean S_REVOKE_LOCK and not ->i_mutex, right?
> >
> > No I did mean the i_mutex since you take the i_mutex when you set
> > S_REVOKE_LOCK.
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
> 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;
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
> 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,
&g
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> Oren Laadan wrote:
> > 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.
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
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
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/
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
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> On 12 December 2007 21:42:25 Serge E. Hallyn wrote:
> > Ok sorry - by letting this thread sit a few days I lost track of where
> > we were.
> >
> > I see now, so you're saying fl_pid for nfs is not in fact a task pid.
>
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> On 12 December 2007 20:31:15 Serge E. Hallyn wrote:
> > Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> > > Hello
> > >
> > > On 6 December 2007 18:51:30 Serge E. Hallyn wrote:
> > > > > fl_pid is use
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> Hello
>
> On 6 December 2007 18:51:30 Serge E. Hallyn wrote:
> > > fl_pid is used by nfs, fuse and gfs2. For instance nfs keeps in fl_pid
> > > some unique id to identify locking process between hosts - it is not a
> &g
Quoting J. Bruce Fields ([EMAIL PROTECTED]):
> On Thu, Dec 06, 2007 at 03:57:29PM +0300, Vitaliy Gusev wrote:
> > I am working on pid namespaces vs locks interaction and want to evaluate
> > the
> > idea.
> > fcntl(F_GETLK,..) can return pid of process for not current pid namespace
> > (if
> >
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> On 6 December 2007 17:53:40 Serge E. Hallyn wrote:
> > Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> > > Hello!
> > >
> > > I am working on pid namespaces vs locks interaction and want to evaluate
> > > the id
Quoting Vitaliy Gusev ([EMAIL PROTECTED]):
> Hello!
>
> I am working on pid namespaces vs locks interaction and want to evaluate the
> idea.
> fcntl(F_GETLK,..) can return pid of process for not current pid namespace (if
> process is belonged to the several namespaces). It is true also for pids
Quoting David P. Quigley ([EMAIL PROTECTED]):
> Originally vfs_getxattr would pull the security xattr variable using
> the inode getxattr handle and then proceed to clobber it with a subsequent
> call
> to the LSM. This patch reorders the two operations such that when the xattr
> requested is in t
Quoting David P. Quigley ([EMAIL PROTECTED]):
> This patch modifies the interface to inode_getsecurity to have the function
> return a buffer containing the security blob and its length via parameters
> instead of relying on the calling function to give it an appropriately sized
> buffer. Security
Quoting David P. Quigley ([EMAIL PROTECTED]):
> On Fri, 2007-10-26 at 10:02 -0500, Serge E. Hallyn wrote:
> > Quoting David P. Quigley ([EMAIL PROTECTED]):
> > > On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
> > > > Quoting David P. Quigley ([EMAIL PROT
Quoting Stephen Smalley ([EMAIL PROTECTED]):
> On Fri, 2007-10-26 at 10:02 -0500, Serge E. Hallyn wrote:
> > Quoting David P. Quigley ([EMAIL PROTECTED]):
> > > On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
> > > > Quoting David P. Quigley ([EMAIL PROT
Quoting David P. Quigley ([EMAIL PROTECTED]):
> On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
> > Quoting David P. Quigley ([EMAIL PROTECTED]):
> > > This patch modifies the interface to inode_getsecurity to have the
> > > function return a buffer containin
Quoting David P. Quigley ([EMAIL PROTECTED]):
> On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote:
> > Quoting David P. Quigley ([EMAIL PROTECTED]):
> > > static int task_alloc_security(struct task_struct *task)
> > > @@ -2423,14 +2
Quoting David P. Quigley ([EMAIL PROTECTED]):
> This patch modifies the interface to inode_getsecurity to have the
> function return a buffer containing the security blob and its length via
> parameters instead of relying on the calling function to give it an
> appropriately sized buffer. Sec
Quoting James Morris ([EMAIL PROTECTED]):
> On Mon, 22 Oct 2007, David P. Quigley wrote:
>
> > Originally vfs_getxattr would pull the security xattr variable using
> > the inode getxattr handle and then proceed to clobber it with a subsequent
> > call
> > to the LSM. This patch reorders the two o
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > >
> > > Add a new filesystem flag, that results in the VFS not checking if the
> > > current process has enough privileges to do an mknod().
> > >
> > > This is needed on filesystems, where an unprivile
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add a new filesystem flag, that results in the VFS not checking if the
> current process has enough privileges to do an mknod().
>
> This is needed on filesystems, where an unprivileged user may be able
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
> Al Viro wrote:
> > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> >> ... or, alternatively, add a subfield to the first field (which would
> >> entail escaping whatever separator we choose):
> >>
> >> /dev/md6 /export ext3 rw,data=ord
Quoting Karl MacMillan ([EMAIL PROTECTED]):
> On Tue, 2007-06-12 at 10:34 -0500, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley ([EMAIL PROTECTED]):
>
> [...]
>
> > >
> > > If we added support for named type transitions to SELinux, as proposed
>
Quoting Stephen Smalley ([EMAIL PROTECTED]):
> On Mon, 2007-06-11 at 14:02 -0500, Serge E. Hallyn wrote:
> > Quoting Andreas Gruenbacher ([EMAIL PROTECTED]):
> > > On Monday 11 June 2007 16:33, Stephen Smalley wrote:
> > > > On Mon, 2007-06-11 at 01:10 +0
Quoting Andreas Gruenbacher ([EMAIL PROTECTED]):
> On Monday 11 June 2007 16:33, Stephen Smalley wrote:
> > On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
> > > On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
> > > > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrot
Quoting Paul Dickson ([EMAIL PROTECTED]):
> On Mon, 14 May 2007 13:23:06 -0700, Badari Pulavarty wrote:
>
> > > + while (fs) {
> > > + locked = union_trylock(fs->root);
> > > + if (!locked)
> > > + goto loop1;
> > > + locked = union_trylock(fs->altroot);
> >
Quoting Suparna Bhattacharya ([EMAIL PROTECTED]):
> On Mon, May 14, 2007 at 08:00:11PM +, Pavel Machek wrote:
> > Hi!
> >
> > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Following are two patches which have bee
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
>
> On May 16 2007 10:38, Bharata B Rao wrote:
> >>
> >> >+lookup_union:
> >> >+ do {
> >> >+ struct vfsmount *mnt = find_mnt(topmost);
> >> >+ UM_DEBUG_DCACHE("name=\"%s\", inode=%p, device=%s\n",
> >> >+ topmost
Quoting Suparna Bhattacharya ([EMAIL PROTECTED]):
> On Thu, May 10, 2007 at 01:01:27PM -0700, Andreas Dilger wrote:
> > On May 08, 2007 16:49 -0500, Serge E. Hallyn wrote:
> > > Quoting Andreas Dilger ([EMAIL PROTECTED]):
> > > > One of the important use cases I c
Quoting Andreas Dilger ([EMAIL PROTECTED]):
> On May 08, 2007 14:17 -0500, Serge E. Hallyn wrote:
> > As the capability set changes and distributions start tagging
> > binaries with capabilities, we would like for running an older
> > kernel to not necessarily make th
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Subject: [PATCH 2/2] file capabilities: accomodate >32 bit capabilities
(Changelog: fixed syntax error in dummy version of check_cap_sanity())
As the capability set changes and distributions start tagging
binaries with capabilities, we would
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Subject: [PATCH 1/2] file capabilities: implement file capabilities
Implement file posix capabilities. This allows programs to be given a
subset of root's powers regardless of who runs them, without having to use
setuid and giving the bi
Following are two patches which have been sitting for some time in -mm.
The first implements file capabilities, the second changes the format a
bit to accomodate potential future 64-bit capabilities.
We are hoping to get a few more eyes on the code before deciding whether
this is safe to finally p
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > So then as far as you're concerned, the patches which were in -mm will
> > > > remain unchanged?
> > >
> > > Basically yes. I've merged the update patch, which was not yet added
> > > to -mm, did so
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > So then as far as you're concerned, the patches which were in -mm will
> > remain unchanged?
>
> Basically yes. I've merged the update patch, which was not yet added
> to -mm, did some cosmetic code changes, and updated the patch headers.
>
> There'
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > Right, I figure if the normal action is to always do
> > > > mnt->user = current->fsuid, then for the special case we
> > > > pass a uid in someplace. Of course... do we not have a
> > > > place to
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Right, I figure if the normal action is to always do
> > mnt->user = current->fsuid, then for the special case we
> > pass a uid in someplace. Of course... do we not have a
> > place to do that? Would it be a no-no to use 'data' for
> > a non-fs-sp
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> >>
> >> Are there other permission checks that mount is doing that we
> >> care about.
>
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting H. Peter Anvin ([EMAIL PROTECTED]):
> >> Miklos Szeredi wrote:
> >> >
> >> > Andrew, please skip this patch, for now.
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Miklos Szeredi <[EMAIL PROTECTED]> writes:
>
> >> From: Miklos Szeredi <[EMAIL PROTECTED]>
> >>
> >> - refine adding "nosuid" and "nodev" flags for unprivileged mounts:
> >> o add "nosuid", only if mounter doesn't have CAP_SETUID capability
> >
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
> Miklos Szeredi wrote:
> >
> > Andrew, please skip this patch, for now.
> >
> > Serge found a problem with the fsuid approach: setfsuid(nonzero) will
> > remove filesystem related capabilities. So even if root is trying to
> > set the "user=UID" flag
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> This patchset has now been bared to the "lowest common denominator"
> that everybody can agree on. Or at least there weren't any objections
> to this proposal.
>
> Andrew, please consider it for -mm.
>
> Thanks,
> Miklos
>
>
> v3 -> v4:
>
> -
Quoting Bharata B Rao ([EMAIL PROTECTED]):
> From: Jan Blunck <[EMAIL PROTECTED]>
> Subject: Introduce union stack.
>
> Adds union stack infrastructure to the dentry structure and provides
> locking routines to walk the union stack.
>
> Signed-off-by: Jan Blunck <[EMAIL PROTECTED]>
> Signed-off-b
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > I'm a bit lost about what is currently done and who advocates for what.
> >
> > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > propagated. In the /share rbind+chroot example, I assume the admin
> > would start by doing
> >
>
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > > 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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > MNT_USER and MNT_USERMNT? I claim no way will people keep those
> > > > straight. How about MNT_ALLOWUSER and MNT_USER?
> > >
> > > Umm, is "allowuser" more clear than "usermnt"? What is allowed to the
> >
> > I think so, yes. One makes it c
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> Why are directory permissions not sufficient to allow/deny non-priveleged
> > mounts?
> >> I don't understand that contention yet.
>
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?
>
> Umm
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> Why are directory permissions not sufficient to allow/deny non-priveleged
> > mounts?
> >> I don't understand that contention yet.
>
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 wit
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 w
Quoting Ram Pai ([EMAIL PROTECTED]):
> 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 querie
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > Agreed on desired behavior, but not on chroot sufficing. It actually
> > > > sounds like you want exactly what was outlined in the OLS paper.
> > > >
> > > > Users still need to be in a different mounts namespace from the admin
> > > > user so l
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > 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 keep
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > 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 remount that
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > 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) {
> > >
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 enough, because user mounts can't be enabled for
> the
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Not objecting to prctl(), but two other options would be
> >
> > 1. add a CLONE_NEW_NS_USERMNT flag - kind of ugly, but that is
> >the time at which the ns is created, so in that sense it
> >makes sense.
>
> Yes, I thought about
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > It would be nice in general if we could avoid any sort of checks for
> > (mnt->mnt_ns == init_nsproxy.mnt_ns). Maybe that won't be possible,
> > but, taking the two listed examples:
>
> [snip]
>
> It's probably worthwile going after these problemat
Quoting Ian Kent ([EMAIL PROTECTED]):
> On Wed, 2007-04-11 at 09:26 -0500, Serge E. Hallyn wrote:
> > Quoting Ian Kent ([EMAIL PROTECTED]):
> > > On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
> > > > > > >>
> > > > > > >>
Quoting Ian Kent ([EMAIL PROTECTED]):
> On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
> > > > >>
> > > > >> - users can use bind mounts without having to pre-configure them in
> > > > >> /etc/fstab
> > > > >>
> > > >
> > > > This is by far the biggest concern I see. I think the secur
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.
Well, I'd like to feel all smart and point out some bugs, but the code
all reads very nicely, seems to
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > One thing that is missing from this series is the ability to restrict
> > > user mounts to private namespaces. The reason is that private
> > > namespaces have still not gained the momentum and support needed for
> > > painless user experience. So
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.
>
> This can be useful for the following reasons:
>
> - mount(8) can store ownership ("user=XY" optio
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > One thing that is missing from this series is the ability to restrict
> > > > > user mounts to private namespaces. The reason is that private
> > > > > namespaces have still not gained the momentum and support needed for
> > > > > painless user
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > This patchset adds support for keeping mount ownership information in
> > > the kernel, and allow unprivileged mount(2) and umount(2) in certain
> > > cases.
> >
> > No replies, huh?
>
> All we need is a comment from Andrew, and the replies come f
1 - 100 of 101 matches
Mail list logo
