Quoting Miklos Szeredi (miklos@szeredi.hu):
quoted text
> 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.

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/