lkml.org 
[lkml]   [2008]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: unprivileged mounts git tree
    Quoting Miklos Szeredi (miklos@szeredi.hu):
    > On Wed, 3 Sep 2008, Serge E. Hallyn wrote:
    > > Quoting Miklos Szeredi (miklos@szeredi.hu):
    > > > 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.
    >
    > Agreed, without privileges it's unacceptable to allow step 3 as is.
    >
    > > 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.
    >
    > Hmm, I think there are infinite ways in which root can mess up mount
    > propagation, and this is not even the worst. I'm not trying to
    > belittle this bug: done unprivileged it's unacceptable. But with
    > privileges, I really don't know if we should change the propagation
    > semantics for this corner case, they are complicated enough already.
    >
    > > > 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.
    >
    > Right, that sounds perfect. the only problem is, bind mount currently
    > ignores the propagation flags, for no good reason I can see.
    >
    > That's a separate patch though. I'll look into it.
    >
    > Thanks,
    > Miklos

    Cool, thanks, Miklos :)

    Are you going to revert the change forcing CL_SLAVE for
    !capable(CAP_SYS_ADMIN)? I don't think we want that - I think that
    *within* a set of user mounts, propagation should be safe, right?

    Will you be able to do this soon? If not, should we just do the part
    returning -EPERM when turning a shared mount into a user mount?
    Because I think that would then be ready for testing in -mm, and would
    love to see it tested.

    Were you going to push a patch to mount to do the user mounts, or
    put sample code in Documentation, git log, or under samples/?

    thanks,
    -serge


    \
     
     \ /
      Last update: 2008-09-04 15:31    [W:3.840 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site