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 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 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? I wanted to get the basics right, before thinking about these details. But getting the semantics of a) right before this is merged is a good idea, of course... So I'll have to think about that. The remount stuff can wait (especially if there will be a new mount API for this kind of thing). > 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. Thanks for looking at this. 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 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)
> > > > 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. I think we agreed, that r-o-bind mounts are more important, so they should go first. They have also received more attention. OTOH there isn't really any fundamental conflict between the two patchsets, so going in together (if the ro-bind patches miss 2.6.25) should also be possible. > Reviewing this stuff properly is still on my todo list, but currently > I'm busy with more important things. 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.) I can set up a git tree for these patches if that makes things easier. Or should I just wait and resubmit after every kernel release, hoping that it becomes _the_ most important thing on Christoph's list ;) 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 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 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 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 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
[patch 00/10] mount ownership and unprivileged mount syscall (v8)
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.
Thanks,
Miklos
v7 -> v8
- extend documentation of allow_usermount sysctl tunable
- describe new unprivileged mounting in fuse.txt
v6 -> v7:
- add '/proc/sys/fs/types//usermount_safe' tunable (new patch)
- do not make FUSE safe by default, describe possible problems
associated with unprivileged FUSE mounts in patch header
- return EMFILE instead of EPERM, if maximum user mount count is exceeded
- rename option 'nomnt' -> 'nosubmnt'
- clean up error propagation in dup_mnt_ns
- update util-linux-ng patch
v5 -> v6:
- update to latest -mm
- preliminary util-linux-ng support (will post right after this series)
v4 -> v5:
- fold back Andrew's changes
- fold back my update patch:
o use fsuid instead of ruid
o allow forced unpriv. unmounts for "safe" filesystems
o allow mounting over special files, but not over symlinks
o set nosuid and nodev based on lack of specific capability
- patch header updates
- new patch: on propagation inherit owner from parent
- new patch: add "no submounts" mount flag
v3 -> v4:
- simplify interface as much as possible, now only a single option
("user=UID") is used to control everything
- no longer allow/deny mounting based on file/directory permissions,
that approach does not always make sense
v1 -> v3:
- add mount flags to set/clear mnt_flags individually
- add "usermnt" mount flag. If it is set, then allow unprivileged
submounts under this mount
- make max number of user mounts default to 1024, since now the
usermnt flag will prevent user mounts by default
--
-
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
