mount --bind accounting
Quoted 3 lines
Quoted 1 line
/* No capabilities? What if users do thousands of these? */
look at
mount_is_safe()
Yes, good. My remark means that more tests are required than those sketched in mount_is_safe(), and that means that for the time being we can throw out the routine mount_is_safe(), and remove the test on capable(CAP_SYS_ADMIN) in do_remount(), and move the same test in do_mount up to the start: all forms of mount require CAP_SYS_ADMIN.
[side effect: remount read-only upon umount of root fs may be possible in a few more cases]
Andries
Quoted 11 lines · On Mon, 4 Jun 2001 [email protected] wrote:
Quoted 3 lines
Quoted 1 line
/* No capabilities? What if users do thousands of these? */
look at
mount_is_safe()Yes, good. My remark means that more tests are required than those sketched in
mount_is_safe(), and that means that for the time being we can throw out the routinemount_is_safe(), and remove the test oncapable(CAP_SYS_ADMIN)indo_remount(), and move the same test indo_mountup to the start: all forms of mount requireCAP_SYS_ADMIN.
Quoted 2 lines
[side effect: remount read-only upon umount of root fs may be possible in a few more cases]
IMO umount / is bogus. For 2.5 we have much better way to unmount everything - as soon as rootfs patch goes in, we will be able to unmount root for real and just fall back to absolute root. Besides, we can simply pass MNT_DETACH to umount(2) and wait until everything goes quiet (see namespace-patch). That has a nice side effect - if some fs is really busy (hung NFS hard mount, leak somewhere, whatever) it will not hold the filesystem it's mounted on. Or prevent clean unmount of filesystems mounted under it, for that matter, even if we would hang trying to look their mountpoints up. Whether it goes into the distributions' shutdown sequences or not, I'm quite happy using it when I do fs stuff - I'm sick and tired of forced fsck on root just because experimental stuff mounted on /mnt decides to hang...