On 4/20/05, Bryan Henderson <[EMAIL PROTECTED]> wrote:
> >In essense, I was
> >thinking of splitting up the concepts of 1) accessing the filesystem on
> >the HDD/device and 2) setting up a namespace for accessing the files
> >into two separate concepts
>
> I've been crusading for years to get peop
>In essense, I was
>thinking of splitting up the concepts of 1) accessing the filesystem on
>the HDD/device and 2) setting up a namespace for accessing the files
>into two separate concepts
I've been crusading for years to get people to understand that a classic
Unix mount is composed of these tw
On Wed, 2005-04-20 at 05:47, Eric Van Hensbergen wrote:
> On 4/19/05, Ram <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
> > >
> > > Is this sufficient to cover any exposure? What's the correct solution
> > > for the shared sub-trees RFC? Should there be so
On 4/19/05, Ram <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
> >
> > Is this sufficient to cover any exposure? What's the correct solution
> > for the shared sub-trees RFC? Should there be something similar for
> > user mounts/binds?
>
> A new namespace in
On Tue, Apr 19, 2005 at 11:38:21PM -0400, Ritesh Kumar wrote:
> You are right. A more priviledged process running as a child of
> another process should not be allowed to look at the same namespace as
> its parent.
No go. That immediately breaks any suid program that takes a pathname
as an argume
You are right. A more priviledged process running as a child of
another process should not be allowed to look at the same namespace as
its parent. However, there is atleast one other example where
something like this exists and there is a counter for that. We can
learn from the counter.
Consider t
On Tue, Apr 19, 2005 at 11:02:53PM -0400, Ritesh Kumar wrote:
> I am new to the list so please bear with me :-)
>
> I have also be thinking about filesystem namespaces which are
> completely under the user's own control.
How do you deal with su(1) finding /etc/shadow in your namespace
and
I am new to the list so please bear with me :-)
I have also be thinking about filesystem namespaces which are
completely under the user's own control. I was also thinking of them
being inherited and changed along the process heirarchy. So a given
process is allowed to change its namespace any way
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
> This is again related to the FUSE permission thread, but a slightly
> different idea and without a slimy hack patch.
>
> I really want to enable users to be able to create private namespaces,
> but I want to try and avoid creating a venerab
This is again related to the FUSE permission thread, but a slightly
different idea and without a slimy hack patch.
I really want to enable users to be able to create private namespaces,
but I want to try and avoid creating a venerability by allowing them
to abuse system resources. It looks like t
10 matches
Mail list logo
