> Checking the permissions on the mountpoint to allow unmounting is
>
> - rather inelegant: user can't see those permissions, can only
> determine if umount is allowed by trial and error
>
> - may be a security hole, e.g.:
>
> sysadmin:
>
> mkdir -m 777 /mnt/disk
>
> > > As I said earlier, I see a case where two mounts that are peers of each
> > > other can become un-identical if we dont propagate the "allowusermnt".
> > >
> > > As a practical example.
> > >
> > > /tmp and /mnt are peers of each other.
> > > /tmp has its "allowusermnt" flag set, which has n
On Wed, 2007-04-18 at 21:14 +0200, Miklos Szeredi wrote:
> > As I said earlier, I see a case where two mounts that are peers of each
> > other can become un-identical if we dont propagate the "allowusermnt".
> >
> > As a practical example.
> >
> > /tmp and /mnt are peers of each other.
> > /tmp h
On Wed, 2007-04-18 at 16:01 +0100, Christoph Hellwig wrote:
> I suspect the right answer here is to make nfs mount handling smarter.
> The way mounting works the filesystem is allowed to choose whether it
> can re-used a superblock or needs a new one. In the NFS case we probably
> want to allow mu
On Wed, 2007-04-18 at 11:19 +0200, Miklos Szeredi wrote:
> > > Allowing this and other flags to NOT be propagated just makes it
> > > possible to have a set of shared mounts with asymmetric properties,
> > > which may actually be desirable.
> >
> > The shared mount feature was designed to ensure t
> >> > I've tried to make this unprivileged mount thing as simple as
> >> > possible, and no simpler. If we can make it even simpler, all the
> >> > better.
> >>
> >> We are certainly much more complex then the code in plan9 (just
> >> read through it) so I think we have room for improvement.
> >
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>> > I've tried to make this unprivileged mount thing as simple as
>> > possible, and no simpler. If we can make it even simpler, all the
>> > better.
>>
>> We are certainly much more complex then the code in plan9 (just
>> read through it) so I think w
> > > Don't forget that almost all mount flags are per-superblock. How are you
> > > planning on dealing with the case that one user mounts a filesystem
> > > read-only, while another is trying to mount the same one read-write?
> >
> > Yeah, I forgot, the per-mount read-only patches are not yet in
On Wed, Apr 18, 2007 at 10:26:29AM -0400, Trond Myklebust wrote:
> > That doesn't really change my agrument though. _If_ the flag is per
> > mount, then it makes sense to be able to change it on a master and not
> > on a slave. If mount flags are propagated, this is not possible.
>
> Read-only i
On Wed, 2007-04-18 at 16:03 +0200, Miklos Szeredi wrote:
> > Don't forget that almost all mount flags are per-superblock. How are you
> > planning on dealing with the case that one user mounts a filesystem
> > read-only, while another is trying to mount the same one read-write?
>
> Yeah, I forgot,
> > > > I've tried to make this unprivileged mount thing as simple as
> > > > possible, and no simpler. If we can make it even simpler, all the
> > > > better.
> > >
> > > We are certainly much more complex then the code in plan9 (just
> > > read through it) so I think we have room for improvemen
On Wed, 2007-04-18 at 11:11 +0200, Miklos Szeredi wrote:
> > > I've tried to make this unprivileged mount thing as simple as
> > > possible, and no simpler. If we can make it even simpler, all the
> > > better.
> >
> > We are certainly much more complex then the code in plan9 (just
> > read throu
> > Allowing this and other flags to NOT be propagated just makes it
> > possible to have a set of shared mounts with asymmetric properties,
> > which may actually be desirable.
>
> The shared mount feature was designed to ensure that the mount remained
> identical at all the locations.
OK, so re
> > I've tried to make this unprivileged mount thing as simple as
> > possible, and no simpler. If we can make it even simpler, all the
> > better.
>
> We are certainly much more complex then the code in plan9 (just
> read through it) so I think we have room for improvement.
>
> Just for referen
On Tue, 2007-04-17 at 21:43 +0200, Miklos Szeredi wrote:
> > > > I'm a bit lost about what is currently done and who advocates for what.
> > > >
> > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > > > propagated. In the /share rbind+chroot example, I assume the admin
>
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>> > I'm still not sure, what your problem is.
>>
>> My problem right now is that I see a serious complexity escalation in
>> the user interface that we must support indefinitely.
>>
>> I see us taking a nice powerful concept and seriously watering it d
> > > I'm a bit lost about what is currently done and who advocates for what.
> > >
> > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > > propagated. In the /share rbind+chroot example, I assume the admin
> > > would start by doing
> > >
> > > mount --bind /share /shar
On Tue, 2007-04-17 at 19:44 +0200, Miklos Szeredi wrote:
> > I'm a bit lost about what is currently done and who advocates for what.
> >
> > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > propagated. In the /share rbind+chroot example, I assume the admin
> > would start by
> > mount --make-rshared /
> > mkdir -p /mnt/ns/$USER
> > mount --rbind / /mnt/ns/$USER
> > mount --make-rslave /mnt/ns/$USER
>
> This was my main point - that the tree in which users can mount will be
> a slave of /, so that propagating the "are user mounts allowed" flag
> among peers is safe and
> > I'm still not sure, what your problem is.
>
> My problem right now is that I see a serious complexity escalation in
> the user interface that we must support indefinitely.
>
> I see us taking a nice powerful concept and seriously watering it down.
> To some extent we have to avoid confusing s
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> I'm still not sure, what your problem is.
My problem right now is that I see a serious complexity escalation in
the user interface that we must support indefinitely.
I see us taking a nice powerful concept and seriously watering it down.
To some exten
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > I'm a bit lost about what is currently done and who advocates for what.
> >
> > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > propagated. In the /share rbind+chroot example, I assume the admin
> > would start by doing
> >
>
> I'm a bit lost about what is currently done and who advocates for what.
>
> It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> propagated. In the /share rbind+chroot example, I assume the admin
> would start by doing
>
> mount --bind /share /share
> mount --make-s
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > > Also for bind-mount and remount operations the flag has to be
> > > > > > propagated
> > > > > > down its propagation tree. Otherwise a unpriviledged mount in a
> > > > > > shared
> > > > > > mount wont get reflected in its peers and slaves
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> Why are directory permissions not sufficient to allow/deny non-priveleged
> > mounts?
> >> I don't understand that contention yet.
> >
> > The same scenarios laid out previously in this thread.
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> Why are directory permissions not sufficient to allow/deny non-priveleged
> > mounts?
> >> I don't understand that contention yet.
> >
> > The same scenarios laid out previously in this thread.
> Interesting
>
> So far even today these things can happen, however they are sufficiently
> unlikely the tools don't account for them.
>
> Once a hostile user can cause them things are more of a problem.
>
> > (Unless you want to tackle each problem legacy tool one at a time to
> > remove p
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>>
>> Why are directory permissions not sufficient to allow/deny non-priveleged
> mounts?
>> I don't understand that contention yet.
>
> The same scenarios laid out previously in this thread. I.e.
>
> 1. user hallyn does mount --bind / /home/hallyn/ro
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Miklos Szeredi <[EMAIL PROTECTED]> writes:
>
> >> > That depends. Current patches check the "unprivileged submounts
> >> > allowed under this mount" flag only on the requested mount and not on
> >> > the propagated mounts. Do you see a problem wit
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>> > That depends. Current patches check the "unprivileged submounts
>> > allowed under this mount" flag only on the requested mount and not on
>> > the propagated mounts. Do you see a problem with this?
>>
>> I think privileges of this sort should pro
> > > > > Also for bind-mount and remount operations the flag has to be
> > > > > propagated
> > > > > down its propagation tree. Otherwise a unpriviledged mount in a
> > > > > shared
> > > > > mount wont get reflected in its peers and slaves, leading to
> > > > > unidentical
> > > > > shared-s
On Mon, 2007-04-16 at 11:56 +0200, Miklos Szeredi wrote:
> > > > Also for bind-mount and remount operations the flag has to be propagated
> > > > down its propagation tree. Otherwise a unpriviledged mount in a shared
> > > > mount wont get reflected in its peers and slaves, leading to unidentical
> > That depends. Current patches check the "unprivileged submounts
> > allowed under this mount" flag only on the requested mount and not on
> > the propagated mounts. Do you see a problem with this?
>
> I think privileges of this sort should propagate. If I read what you
> just said correctly
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> That depends. Current patches check the "unprivileged submounts
> allowed under this mount" flag only on the requested mount and not on
> the propagated mounts. Do you see a problem with this?
I think privileges of this sort should propagate. If I r
> > > Also for bind-mount and remount operations the flag has to be propagated
> > > down its propagation tree. Otherwise a unpriviledged mount in a shared
> > > mount wont get reflected in its peers and slaves, leading to unidentical
> > > shared-subtrees.
> >
> > That's an interesting question.
On Mon, 2007-04-16 at 11:32 +0200, Miklos Szeredi wrote:
> > > Given the existence of shared subtrees allowing/denying this at the
> > > mount
> > > namespace level is silly and wrong.
> > >
> > > If we need more than just the filesystem permission checks can we
> > > make it a mount flag settable
> > Given the existence of shared subtrees allowing/denying this at the
> > mount
> > namespace level is silly and wrong.
> >
> > If we need more than just the filesystem permission checks can we
> > make it a mount flag settable with mount and remount that allows
> > non-privileged users the abil
>
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> >> From: Miklos Szeredi <[EMAIL PROTECTED]>
> >>
> >> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> >> unshare(2), then allow user mounts within the new namespace.
> >>
> >
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
>> > Given the existence of shared subtrees allowing/denying this at the mount
>> > namespace level is silly and wrong.
>> >
>> > If we need more than just the filesystem permission checks can we
>> > make
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Given the existence of shared subtrees allowing/denying this at the mount
> > namespace level is silly and wrong.
> >
> > If we need more than just the filesystem permission checks can we
> > make it a mount flag settable with mount and remount that
> Given the existence of shared subtrees allowing/denying this at the mount
> namespace level is silly and wrong.
>
> If we need more than just the filesystem permission checks can we
> make it a mount flag settable with mount and remount that allows
> non-privileged users the ability to create mo
> question: how is mounting filesystems (loopback,
> fuse, etc) secured in such way that the user
> cannot 'create' device nodes with 'unfortunate'
> permissions?
All unprivileged mounts have "nosuid,nodev" added to their options.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
>> From: Miklos Szeredi <[EMAIL PROTECTED]>
>>
>> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
>> unshare(2), then allow user mounts within the new namespace.
>>
>> This is not flexible
On Thu, Apr 12, 2007 at 03:32:08PM -0500, Serge E. Hallyn wrote:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> > unshare(2), then allow user mounts within the new namespace.
> >
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> unshare(2), then allow user mounts within the new namespace.
>
> This is not flexible enough, because user mounts can't be enabled for
> the
From: Miklos Szeredi <[EMAIL PROTECTED]>
If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
unshare(2), then allow user mounts within the new namespace.
This is not flexible enough, because user mounts can't be enabled for
the initial namespace.
The remaining clone bits also getting
46 matches
Mail list logo
