David Howells <dhowells@xxxxxxxxxx> writes: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > >> > Also you can't currently directly create a bind mount from userspace as you >> > can only bind from another path point - which you may not be able to access >> > (either by permission failure or because it's not in your mount namespace). >> > >> >> Are you trying to preserve the magic bind semantics with the new API? > > No, I'm pointing out that you can't emulate this by doing a bind mount from > userspace if you can't access the thing you're binding from. > > Now, we could create a syscall that just picks up an extant superblock using a > device and attaches it to a mount for you, but that would have to be at least > partially parameterised - which would be very fs-dependent - so that it can > know whether or not you're allowed to create another mount to that sb. > > What you're talking about is emulating sget() in userspace - when we have to > do it in the kernel anyway if we still offer mount(2). I am just going to chime in and say that it is absolutely a problem in the current mount interface that when I mount a filesystem with fresh parameters I don't know if it is generates an sget and a new super_block or if it just increments the refcount on an existing super_block. It is the kind of problem that is actually security sensitive and has resulted in a security issue in the current linux kernel with respect to proc. So yes we absolutely need to have a clean way of dealing with: mount /dev/sda3 /tmp mount /dev/sda3 /mnt So that the second one is forbidden fails. And userspace has to do the equivalent of sget to get a file descriptor it can bind into the mount namespace. The deep problem is that the second mount does not parse the mount options and userspace does not know that. So userspace thinks it is getting one kind of mount and in practice it gets another (sometimes with different security properties). Those different security properties are an out and out bug. Although any kind of different and unexpected properties can be a problem. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
