Quoting Miklos Szeredi (miklos@xxxxxxxxxx): > On Wed, 3 Sep 2008, Serge E. Hallyn wrote: > > Ooh. > > > > You predicate the turning of shared mount to a slave mount on > > !capable(CAP_SYS_ADMIN). But in fact it's the mount by a privileged > > user, turning the mount into a user mount, which you want to convert. > > So my series of steps was: > > > > as root: > > (1) mount --bind /mnt /mnt > > (2) mount --make-rshared /mnt > > (3) /usr/src/mmount-0.3/mmount --bind -o user=hallyn /mnt \ > > /home/hallyn/etc/mnt > > as hallyn: > > (4) mount --bind /usr /home/hallyn/etc/mnt/usr > > > > You are turning mounts from shared->slave at step 4, but in fact we need > > to do it at step 3, where we do have CAP_SYS_ADMIN. > > Well, that's arguable: I think root should be able to shoot itself in > the foot by doing step 3. Maybe I'm not thinking right, but long-term is there any reason why we should require privilege in order to do step 3, so long as the user has read access to the source and write access to the destination? I don't think there is. Other than this glitch. That's a powerful reason to fix the glitch. The other argument is that, frankly, I think most people are still either unaware of, or confused by, mounts propagation. Letting root shoot himself in the foot is reasonable only to a point. > Generally we don't restrict what root can > do. OTOH I agree that current behavior is ugly in that it provides > different semantics for privileged/non-privileged callers. > > Perhaps it would be cleaner to simply not allow step 4, instead of > playing tricks with changing the propagation type. If the user or admin can simply (I haven't tested) mmount --bind --make-rslave -o user=hallyn /mnt \ /home/hallyn/etc/mnt then returning -EPERM if --make-rslave was not provided is reasonable IMO. -serge -- 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
