> 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
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 not been propagated
to
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
mount
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
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
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
> >> > 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
> > > 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
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
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
> > > > 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
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
> > 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
> > 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
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 reference what I
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 remount
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 through it) so I
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
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, the
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 isn't
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.
That
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 we have room for
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 reference
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 that the
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
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 has its
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
> > > 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
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
> > 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
> > 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
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
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
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
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
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
> 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
"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 /
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/root
2. (...)
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 problems -
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. I.e.
1. user
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. I.e.
1. user
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, leading to
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-slave
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
mount
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 extent
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 suid
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 intuitive.
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 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
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
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
would start
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
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
> > > > > 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
> > > > >
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
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
> > > 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
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
> > 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
>
> "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]):
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
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
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 with mount and
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. Do we want
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 read
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 if I have
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
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
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
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 with this?
I
76 matches
Mail list logo
