Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Mon, Feb 18, 2008 at 12:47:59PM +0100, Miklos Szeredi wrote: So what should I do? Would Al be wanting to merge this into his VFS tree? (Can't find it on git.kernel.org yet, BTW.) FWIW, it's on hera right now, should propagate to git.kernel.org in a few. Branches I'd pushed there: vfs-fixes.b0 and ro-bind.b0. The latter is on top of the former. There will be more, but that at least takes care of the most urgent stuff. Again, apologies for things being too damn slow ;-/ As for the unprivileged mounts... a) why do we lose them on clone() in new namespace? Bloody inconvenient, to put it mildly. b) why do we prohibit all kinds of remount? c) just what is limited by that sysctl? AFAICS, rbind is allowed if mountpoint is on user vfsmount and it seems to create vfsmounts without eating into that limit just fine... What's the point of limiting the amount of vfsmounts marked user when you do not limit the number of vfsmount one can allocate? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Sat, Feb 23, 2008 at 06:33:13PM +0100, Miklos Szeredi wrote: c) just what is limited by that sysctl? AFAICS, rbind is allowed if mountpoint is on user vfsmount and it seems to create vfsmounts without eating into that limit just fine... What's the point of limiting the amount of vfsmounts marked user when you do not limit the number of vfsmount one can allocate? The limit is there, so that unprivileged users cannot create insane number of mounts. It's just a safety thing, analogous to /proc/sys/fs/file-max. Can't they? Looks like one can create any number of vfsmounts without getting more than one marked MNT_USER... What are you trying to limit - vfsmounts or superblocks? The former is not limited in your patchset at all, AFAICS - you can do while true; do mount --bind /bin ~/my_directory; mount --bind /sbin ~/my_directory; done indefinitely and all the bleeding stack of vfsmounts will be !MNT_USER. Or any number of similar schemes, really, without overmounting if you wish to avoid it. If you are trying to limit the number of superblocks (i.e. active instances of filesystems), then I'd say that vfsmounts make piss-poor proxies for those and it would be better to count the objects you really want to count... - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Sat, Feb 23, 2008 at 06:33:13PM +0100, Miklos Szeredi wrote: c) just what is limited by that sysctl? AFAICS, rbind is allowed if mountpoint is on user vfsmount and it seems to create vfsmounts without eating into that limit just fine... What's the point of limiting the amount of vfsmounts marked user when you do not limit the number of vfsmount one can allocate? The limit is there, so that unprivileged users cannot create insane number of mounts. It's just a safety thing, analogous to /proc/sys/fs/file-max. Can't they? Looks like one can create any number of vfsmounts without getting more than one marked MNT_USER... permit_mount() will set MS_SETUSER in flags, and do_loopback() will set CL_SETUSER based on that flag. If you are trying to limit the number of superblocks (i.e. active instances of filesystems), then I'd say that vfsmounts make piss-poor proxies for those and it would be better to count the objects you really want to count... I think I really want to limit vfsmounts. But not because these take so much memory or anything, just to be safe against a stupid users playing rbind and propagation, and things like that. Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Thu, Feb 14, 2008 at 10:21:03PM -0800, Andrew Morton wrote: Linus has just merged all the VFS renaming patches, so the decks are clear for looking at this work. However David and Christoph are beavering away on the r-o-bind-mounts patches and I expect that there will be overlaps with unprivileged mounts. Could we coordinate things a bit please? Decide who goes first, review and maybe even test each others work, etc? Al is setting up a git tree for VFS work. per-mount r/o will go in as one of the first things, aswell as his rework of the path lookup logic to fix the intents mess. Thanks. ---end quoted text--- - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Fri, 15 Feb 2008 04:01:20 -0500 Christoph Hellwig [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 10:21:03PM -0800, Andrew Morton wrote: Linus has just merged all the VFS renaming patches, so the decks are clear for looking at this work. However David and Christoph are beavering away on the r-o-bind-mounts patches and I expect that there will be overlaps with unprivileged mounts. Could we coordinate things a bit please? Decide who goes first, review and maybe even test each others work, etc? Al is setting up a git tree for VFS work. per-mount r/o will go in as one of the first things, aswell as his rework of the path lookup logic to fix the intents mess. That didn't answer my question.. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Fri, Feb 15, 2008 at 01:09:51AM -0800, Andrew Morton wrote: However David and Christoph are beavering away on the r-o-bind-mounts patches and I expect that there will be overlaps with unprivileged mounts. Could we coordinate things a bit please? Decide who goes first, review and maybe even test each others work, etc? Al is setting up a git tree for VFS work. per-mount r/o will go in as one of the first things, aswell as his rework of the path lookup logic to fix the intents mess. That didn't answer my question.. Well, Al as the defacto VFS maintainer will decide on the ordering. Reviewing this stuff properly is still on my todo list, but currently I'm busy with more important things. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)
On Tue, 05 Feb 2008 22:36:16 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote: Just documentation updates, compared to the previous submission. Thanks to Serge for the relentless reviews :) Please consider for -mm, and then for 2.6.26. Linus has just merged all the VFS renaming patches, so the decks are clear for looking at this work. However David and Christoph are beavering away on the r-o-bind-mounts patches and I expect that there will be overlaps with unprivileged mounts. Could we coordinate things a bit please? Decide who goes first, review and maybe even test each others work, etc? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
