On Sat, Jun 17, 2006 at 02:10:17AM +0200, Grzegorz Kulewski wrote: > On Fri, 16 Jun 2006, Dave Hansen wrote: > >On Sat, 2006-06-17 at 01:29 +0200, Grzegorz Kulewski wrote: > >>Isn't this some kind of security risk (at least in my planned use)? I mean > >>- for a small fraction of second somebody seeing /dest can write > >>/source... No? > > > >I assume you're talking about this kind of situation: > > > >mount --bind /local/writable/dir /chroot/untrusted/area/ > >mount --o remount,ro /chroot/untrusted/area/ > > Well, actually about some kind of VPS: openvz or something like that. > But yes, this is the same kind of scenario. yes, Linux-VServer provides this kind of ro --bind mounts without the race, as the the flags are passed on the actual mount > >This has no r/w window in the chroot area: > > > >mount --bind /local/writable/dir /tmp/area/ > >mount --o remount,ro /tmp/area/ > >mount --bind /tmp/area/ /chroot/untrusted/area/ > >umount /tmp/area/ > > Well, it looks a little scarry and complicated at first. And probably > requires you to know that semantic of --bind lets you do the last > unmount. But if you are saying that this makes kernel smaller, faster > and less buggy then you are probably very right. well, it makes the kernel more consistant in it's behaviour, because especially for --rbind mounts, the logic what is changed where and when is not as well defined as one would wish ... btw, you could get the same result by simply doing: mount --bind /local/writable/dir /tmp/area/ mount --o remount,ro /tmp/area/ mount --move /tmp/area/ /chroot/untrusted/area/ without the duplicate mount and the unmount HTH, Herbert > Thank you for your explanation, > > Grzegorz Kulewski - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
