Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > > > think that would make a lot of sense anyway.
> > > >
> > > > Would it be as simple as tagging the inodes with capability sets? One
> > > > set for writing, or one
> On Tue, Feb 05, 2008 at 10:36:23PM +0100, Miklos Szeredi wrote:
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add the following:
> >
> > /proc/sys/fs/types/${FS_TYPE}/usermount_safe
> >
>
>
> There is /proc/fs// already. Since it is file system specific
> shouldn't it go there ?
On Tue, Feb 05, 2008 at 10:36:23PM +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
There is /proc/fs// already. Since it is file system specific
shouldn't it go there ?
-aneesh
--
To
> > > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > > think that would make a lot of sense anyway.
> > >
> > > Would it be as simple as tagging the inodes with capability sets? One
> > > set for writing, or one each for reading and writing?
> >
> > Yes, or something
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > think that would make a lot of sense anyway.
> >
> > Would it be as simple as tagging the inodes with capability sets? One
> > set for writing, or one each for reading and
> > Maybe sysctls just need to check capabilities, instead of uids. I
> > think that would make a lot of sense anyway.
>
> Would it be as simple as tagging the inodes with capability sets? One
> set for writing, or one each for reading and writing?
Yes, or something even simpler, like mapping
Maybe sysctls just need to check capabilities, instead of uids. I
think that would make a lot of sense anyway.
Would it be as simple as tagging the inodes with capability sets? One
set for writing, or one each for reading and writing?
Yes, or something even simpler, like mapping the
On Tue, Feb 05, 2008 at 10:36:23PM +0100, Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
There is /proc/fs/type/ already. Since it is file system specific
shouldn't it go there ?
The problem is
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Maybe sysctls just need to check capabilities, instead of uids. I
think that would make a lot of sense anyway.
Would it be as simple as tagging the inodes with capability sets? One
set for writing, or one each for reading and writing?
On Tue, Feb 05, 2008 at 10:36:23PM +0100, Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
There is /proc/fs/type/ already. Since it is file system specific
shouldn't it go there ?
-aneesh
--
To unsubscribe
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Maybe sysctls just need to check capabilities, instead of uids. I
think that would make a lot of sense anyway.
Would it be as simple as tagging the inodes with capability sets? One
set for writing, or one each for reading and
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > + t->table[0].mode = 0644;
> >
> > Yikes, this could be a problem for containers, as it's simply tied to
> > uid 0, whereas tying it to a capability would let us solve it with
> > capability bounds.
> >
> > This might mean more urgency to get
> > + t->table[0].mode = 0644;
>
> Yikes, this could be a problem for containers, as it's simply tied to
> uid 0, whereas tying it to a capability would let us solve it with
> capability bounds.
>
> This might mean more urgency to get user namespaces working at least
> with sysfs, else this is
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
> Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Thanks, Miklos, good explanations in the docs.
Acked-by: Serge Hallyn <[EMAIL
+ t-table[0].mode = 0644;
Yikes, this could be a problem for containers, as it's simply tied to
uid 0, whereas tying it to a capability would let us solve it with
capability bounds.
This might mean more urgency to get user namespaces working at least
with sysfs, else this is a quick
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
+ t-table[0].mode = 0644;
Yikes, this could be a problem for containers, as it's simply tied to
uid 0, whereas tying it to a capability would let us solve it with
capability bounds.
This might mean more urgency to get user namespaces
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > What do you think about doing this only if FS_SAFE is also set,
> > > > so for instance at first only FUSE would allow itself to be
> > > > made user-mountable?
> > > >
> > > > A safe thing to do, or overly intrusive?
> > >
> > > It goes
> > > What do you think about doing this only if FS_SAFE is also set,
> > > so for instance at first only FUSE would allow itself to be
> > > made user-mountable?
> > >
> > > A safe thing to do, or overly intrusive?
> >
> > It goes somewhat against the "no policy in kernel" policy ;). I think
>
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > What do you think about doing this only if FS_SAFE is also set,
> > so for instance at first only FUSE would allow itself to be
> > made user-mountable?
> >
> > A safe thing to do, or overly intrusive?
>
> It goes somewhat against the "no policy in
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
What do you think about doing this only if FS_SAFE is also set,
so for instance at first only FUSE would allow itself to be
made user-mountable?
A safe thing to do, or overly intrusive?
It goes somewhat against the no policy in kernel
What do you think about doing this only if FS_SAFE is also set,
so for instance at first only FUSE would allow itself to be
made user-mountable?
A safe thing to do, or overly intrusive?
It goes somewhat against the no policy in kernel policy ;). I think
the warning in the
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
What do you think about doing this only if FS_SAFE is also set,
so for instance at first only FUSE would allow itself to be
made user-mountable?
A safe thing to do, or overly intrusive?
It goes somewhat against the no policy
> What do you think about doing this only if FS_SAFE is also set,
> so for instance at first only FUSE would allow itself to be
> made user-mountable?
>
> A safe thing to do, or overly intrusive?
It goes somewhat against the "no policy in kernel" policy ;). I think
the warning in the
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
> Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
> ---
>
> Index: linux/fs/filesystems.c
>
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/filesystems.c
What do you think about doing this only if FS_SAFE is also set,
so for instance at first only FUSE would allow itself to be
made user-mountable?
A safe thing to do, or overly intrusive?
It goes somewhat against the no policy in kernel policy ;). I think
the warning in the documentation
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c
30 matches
Mail list logo
