> > Does this mean, that containers will need this? Or that you don't
> > know yet?
>
> The uid namespace is something we have to handle carefully and we
> have not decided on the final design.
>
> What is clear is that all permission checks will need to become
> either (uid namspace, uid) tuple
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> Does this mean, that containers will need this? Or that you don't
> know yet?
The uid namespace is something we have to handle carefully and we
have not decided on the final design.
What is clear is that all permission checks will need to become
eith
> I suspect we can allow MNT_FORCE for non-privileged users
> as well if we can trust the filesystem.
I don't think so. MNT_FORCE has side effects on the superblock. So a
user shouldn't be able to force an unmount on a bind mount s/he did,
but there's no problem with allowing plain/lazy unm
> > On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> >> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
> >> > > +{
> >> > >
> >> > > ...
> >> > >
> >> > > + return mnt->mnt_uid == current->uid;
> >> > > +}
> >> >
> >> > Yes, this seems very w
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> The owner doesn't need sysadmin capabilities to call umount().
>
> Similar behavior as umount(8) on mounts having "user=UID" option in
> /etc/mtab. The difference is that umount also checks /etc/fstab,
> pre
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
>> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
>> > > +{
>> > >
>> > > ...
>> > >
>> > > +return mnt->mnt_uid == current->uid;
>> > > +}
>> >
>> >
On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
> > > +{
> > >
> > > ...
> > >
> > > + return mnt->mnt_uid == current->uid;
> > > +}
> >
> > Yes, this seems very wrong. I'd have thought that comparing
> > +static bool permit_umount(struct vfsmount *mnt, int flags)
> > +{
> >
> > ...
> >
> > + return mnt->mnt_uid == current->uid;
> > +}
>
> Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
> would get us a heck of a lot closer to being able to support aliasing of
> UI
Andrew Morton wrote:
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
+static bool permit_umount(struct vfsmount *mnt, int flags)
+{
...
+ return mnt->mnt_uid == current->uid;
+}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
wo
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> +static bool permit_umount(struct vfsmount *mnt, int flags)
> +{
>
> ...
>
> + return mnt->mnt_uid == current->uid;
> +}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
would get us a he
From: Miklos Szeredi <[EMAIL PROTECTED]>
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having "user=UID" option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to exclude another mount on the same mountpoint.
11 matches
Mail list logo