"Serge E. Hallyn" <serue@us.ibm.com> writes:

> (Updated patchset addressing Paul's comments.  Still looking more
> for discussion on functionality, but barring much of that I guess
> I'll do something with tsk->fs then send the set to lkml)
>
> The following patchset uses the ns container subsystem to implement
> namespace entering.  It applies over the container patchset Paul
> sent out earlier today.
>

Let's describe the problem.  There are two usage scenarios.
- Working with the parameters of an existing namespace.
  (For example: changing or reading the hostname of a container you are not
   in, or setting/reading various resource limits).
- Logging in to an existing namespace.  I.e. You are the uber sysadmin
  and the person running a container has a problem or something similar.

Until we work through the details of the pid namespace there are going
to be details of this we cannot finalize, because we will not have finalized
how traditional process groups work.  Something more for my todo guess.

I have given this some though and I can describe how far we can go without
implementing a traditional enter, which is a very long ways.



For the general management functions most things already have or can
have added a filesystem interface, and we just need to make that
filesystem interface per process...

That is we can do like what is currently done with /proc/mounts and
make /proc/sys a symlink to /proc/self/sys and /proc/<otherpid>/sys 
can be that other processes view of all of the sysctls.

We can do the same thing with /proc/net, and /proc/sysvipc and
possibly /sys/net although that is a more difficult.  sysfs is a pain
to work with.



For the actual enter functionality what is currently possible is ugly
to implement but extremely close to something useful.  You can use
sys_ptrace and pick a random process and with a little care cause
it to fork and exec the executable of your choice.  With these
manipulations you can create things like unix domain sockets and
pipes and that can be used to talk with the parent process.  It has
been a while since I have done this so I don't remember the exact
limits are but I have gotten a fully functional login shell this way.
The big practical problem was who is the parent process.
CAP_SYS_PTRACE is the governing capability here.
I've got the code around someplace for doing this if you are curious.

If we optimize/cleanup this case it looks a lot like what (I think it
was Cedric) was proposing about a year ago.  A magic fork that does
the enter for you.  Since the caller controls the binary we don't
have the usual concerns about the magic fork becoming spawn, because
we can program the binary to do anything else it needs after the fork.

> This is RFC not just on implementation, but also on whether to do
> it at all.  If so, then for all namespace, or only some?  And if not,
> how to facilitate virtual server management.

My gut feeling is the best way to go is something that is a refinement
of the two techniques I have listed above.

>
> = Security =
>
> Currently to enter a namespace, you must have CAP_SYS_ADMIN, and must
> be entering a container which is an immediate child of your current
> container.  So from the root container you could enter container /vserver1,
> but from container /vserver1 you could not enter /vserver2 or the root
> container.
>
> This may turn out to be sufficient.  If not, then LSM hooks should be
> added for namespace management.  Four hooks for nsproxy management (create,
> compose, may_enter, and enter), as well as some security_ns_clone hook for
> each separate namespace, so that the nsproxy enter and compose hooks have
> the information they need to properly authorize.

You miss an issue here.  One of the dangers of enter is leaking
capabilities into a contained set of processes.   Once you show up in
/proc processes can change into your working directory which is
outside of the container for example.

> = Quick question =
>
> Is it deemed ok to allow entering an existing namespace?
>
> If so, the next section can be disregarded.  Assuming not, the following
> will need to be worked out.

I think we need to take a good hard look at the alternatives, because
the are very functional.

> = Management alternatives =
>
> Mounts
>
> Ram has suggested that for mounts, instead of implementing namespace
> entering, the example from the OLS Shared Subtree paper could be
> used, as follows (quoting from Ram):

Does anyone know why we have the shared subtree entering instead of
a enter on a fs namespace?  I'm curious about the reasoning for that
design decision.

> Herbert, and anyone else who wants mounts namespace entering, is the
> above an acceptable alternative?
>
> net+pid+uts
>
> Not sure about uts, but I'm pretty sure the vserver folks want the ability
> to enter another existing network namespace, and both vserver and openvz
> have asked for the ability to enter pid namespaces.
>
> The pid namespaces could be solved by always generating as many pids for
> a process as it has parent pid_namespaces.  So if I'm in /vserver1, with
> one pid_namespace above me, not only my init process has an entry in the
> root pid_namespace (as I think has been suggested), but all my children
> will also continue to have pids in the root pid_namespace.

Yes.  This looks to be the most sensible thing and now that we have
struct pid we don't have to special case anything to implement a
pid showing up in multiple pid namespaces.  So it is my expectation
that each process will show up in the pid namespace of all of it's
parents up to init.

> Or, if it is ok for the pid namespace operations to be as coarse as
> "kill all processes in /vserver1", then that was going to be implemented
> using the namespace container subsystem as:
>
> 	rm -rf /container_ns/vserver1

To some extent I have an issue with this since we have kill and
signals and other mechanisms already existing for most of this
the duplication at the very least seems silly.

> Any other (a) requirements, (b) ideas for alternate pid and network
> ns management without allowing namespace enters?


See above.

I'm stretched pretty thin at the moment, so this will have to do for
a first set of comments.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> > (Updated patchset addressing Paul's comments.  Still looking more
> > for discussion on functionality, but barring much of that I guess
> > I'll do something with tsk->fs then send the set to lkml)
> >
> > The following patchset uses the ns container subsystem to implement
> > namespace entering.  It applies over the container patchset Paul
> > sent out earlier today.
> >
> 
> Let's describe the problem.  There are two usage scenarios.
> - Working with the parameters of an existing namespace.
>   (For example: changing or reading the hostname of a container you are not
>    in, or setting/reading various resource limits).
> - Logging in to an existing namespace.  I.e. You are the uber sysadmin
>   and the person running a container has a problem or something similar.
> 
> Until we work through the details of the pid namespace there are going
> to be details of this we cannot finalize, because we will not have finalized
> how traditional process groups work.  Something more for my todo guess.
> 
> I have given this some though and I can describe how far we can go without
> implementing a traditional enter, which is a very long ways.
> 
> 
> 
> For the general management functions most things already have or can
> have added a filesystem interface, and we just need to make that
> filesystem interface per process...
> 
> That is we can do like what is currently done with /proc/mounts and
> make /proc/sys a symlink to /proc/self/sys and /proc/<otherpid>/sys 
> can be that other processes view of all of the sysctls.
> 
> We can do the same thing with /proc/net, and /proc/sysvipc and
> possibly /sys/net although that is a more difficult.  sysfs is a pain
> to work with.
> 
> 
> 
> For the actual enter functionality what is currently possible is ugly
> to implement but extremely close to something useful.  You can use
> sys_ptrace and pick a random process and with a little care cause
> it to fork and exec the executable of your choice.  With these
> manipulations you can create things like unix domain sockets and
> pipes and that can be used to talk with the parent process.  It has
> been a while since I have done this so I don't remember the exact
> limits are but I have gotten a fully functional login shell this way.
> The big practical problem was who is the parent process.
> CAP_SYS_PTRACE is the governing capability here.
> I've got the code around someplace for doing this if you are curious.
> 
> If we optimize/cleanup this case it looks a lot like what (I think it
> was Cedric) was proposing about a year ago.  A magic fork that does
> the enter for you.  Since the caller controls the binary we don't
> have the usual concerns about the magic fork becoming spawn, because
> we can program the binary to do anything else it needs after the fork.
> 
> > This is RFC not just on implementation, but also on whether to do
> > it at all.  If so, then for all namespace, or only some?  And if not,
> > how to facilitate virtual server management.
> 
> My gut feeling is the best way to go is something that is a refinement
> of the two techniques I have listed above.
> 
> >
> > = Security =
> >
> > Currently to enter a namespace, you must have CAP_SYS_ADMIN, and must
> > be entering a container which is an immediate child of your current
> > container.  So from the root container you could enter container /vserver1,
> > but from container /vserver1 you could not enter /vserver2 or the root
> > container.
> >
> > This may turn out to be sufficient.  If not, then LSM hooks should be
> > added for namespace management.  Four hooks for nsproxy management (create,
> > compose, may_enter, and enter), as well as some security_ns_clone hook for
> > each separate namespace, so that the nsproxy enter and compose hooks have
> > the information they need to properly authorize.
> 
> You miss an issue here.  One of the dangers of enter is leaking
> capabilities into a contained set of processes.   Once you show up in

Good point.  As wrong as it feels to me to use ptrace for this, the
advantage is that none of my task attributes leak into the target
namespace, and that's a very good thing.

I do wonder how you specify what the forced clone should run.
Presumably you want to run something not in the target container.
I suppose we can pass the fd over a socket or something.

Herbert, does this sound like it suffices to you?  Of course, it does
mean that you cannot switch just a few namespaces.  How does that limit
you?

> /proc processes can change into your working directory which is
> outside of the container for example.

I suppose I could get into specific ways that this could be prevented
from being exploited, but for now I'll just stick to agreeing that there
would be a whole bunch of issues like this, and we'd likely miss more
than one.

> > = Quick question =
> >
> > Is it deemed ok to allow entering an existing namespace?
> >
> > If so, the next section can be disregarded.  Assuming not, the following
> > will need to be worked out.
> 
> I think we need to take a good hard look at the alternatives, because
> the are very functional.
> 
> > = Management alternatives =
> >
> > Mounts
> >
> > Ram has suggested that for mounts, instead of implementing namespace
> > entering, the example from the OLS Shared Subtree paper could be
> > used, as follows (quoting from Ram):
> 
> Does anyone know why we have the shared subtree entering instead of
> a enter on a fs namespace?  I'm curious about the reasoning for that
> design decision.
> 
> > Herbert, and anyone else who wants mounts namespace entering, is the
> > above an acceptable alternative?
> >
> > net+pid+uts
> >
> > Not sure about uts, but I'm pretty sure the vserver folks want the ability
> > to enter another existing network namespace, and both vserver and openvz
> > have asked for the ability to enter pid namespaces.
> >
> > The pid namespaces could be solved by always generating as many pids for
> > a process as it has parent pid_namespaces.  So if I'm in /vserver1, with
> > one pid_namespace above me, not only my init process has an entry in the
> > root pid_namespace (as I think has been suggested), but all my children
> > will also continue to have pids in the root pid_namespace.
> 
> Yes.  This looks to be the most sensible thing and now that we have
> struct pid we don't have to special case anything to implement a
> pid showing up in multiple pid namespaces.  So it is my expectation
> that each process will show up in the pid namespace of all of it's
> parents up to init.

In fact we were thinking there could be an additional clone flag when
doing CLONE_PIDNS to determine whether all processes get pids in all
ancestor pid_namespaces or not, since really the only change should be
an overhead at clone() for allocing and linking the additional struct
pid_nr's.

> > Or, if it is ok for the pid namespace operations to be as coarse as
> > "kill all processes in /vserver1", then that was going to be implemented
> > using the namespace container subsystem as:
> >
> > 	rm -rf /container_ns/vserver1
> 
> To some extent I have an issue with this since we have kill and
> signals and other mechanisms already existing for most of this
> the duplication at the very least seems silly.

But you don't really.  If I want to kill all processes in a child
container, I don't have an easy way to list only the processes in the
child container using, say, ps.  Those processes are just lumped in with
my own, and with those from all my other child containers.

So we'd end up looping over all pids, checking their ->container, then
killing them, and hoping that nothing funky happens meanwhile like that
process dies and pids wrap around while i'm sleeping (ok, unlikely, but
not impossible).

I'm not saying I'm hung up on doing it with an rm /container_ns/vs1.  If
the only use for the ns container subsystem ends up being to tie
resource management to containers, I'll be very happy.

> > Any other (a) requirements, (b) ideas for alternate pid and network
> > ns management without allowing namespace enters?
> 
> 
> See above.
> 
> I'm stretched pretty thin at the moment, so this will have to do for
> a first set of comments.

Thanks for your time, Eric.

-serge
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> 
>> You miss an issue here.  One of the dangers of enter is leaking
>> capabilities into a contained set of processes.   Once you show up in
>
> Good point.  As wrong as it feels to me to use ptrace for this, the
> advantage is that none of my task attributes leak into the target
> namespace, and that's a very good thing.
>
> I do wonder how you specify what the forced clone should run.
> Presumably you want to run something not in the target container.
> I suppose we can pass the fd over a socket or something.

Yes.  At least in the case without a network namespace I can setup
a unix domain socket and pass file descriptors around.  I think my solution
to the network namespace case was to just setup a unix domain socket in
the parent namespace and leave it open in init.  Not a real solution :(

> Herbert, does this sound like it suffices to you?  Of course, it does
> mean that you cannot switch just a few namespaces.  How does that limit
> you?
>
>> /proc processes can change into your working directory which is
>> outside of the container for example.
>
> I suppose I could get into specific ways that this could be prevented
> from being exploited, but for now I'll just stick to agreeing that there
> would be a whole bunch of issues like this, and we'd likely miss more
> than one.

Thanks.  I think what we want is an API where what is leaked is an
explicit decision rather then everything leaking implicitly and the
user space programmer has to run around and close all of the holes.

>> Yes.  This looks to be the most sensible thing and now that we have
>> struct pid we don't have to special case anything to implement a
>> pid showing up in multiple pid namespaces.  So it is my expectation
>> that each process will show up in the pid namespace of all of it's
>> parents up to init.
>
> In fact we were thinking there could be an additional clone flag when
> doing CLONE_PIDNS to determine whether all processes get pids in all
> ancestor pid_namespaces or not, since really the only change should be
> an overhead at clone() for allocing and linking the additional struct
> pid_nr's.

I doubt it is worth the hassle of making the code conditional.

>> > Or, if it is ok for the pid namespace operations to be as coarse as
>> > "kill all processes in /vserver1", then that was going to be implemented
>> > using the namespace container subsystem as:
>> >
>> > 	rm -rf /container_ns/vserver1
>> 
>> To some extent I have an issue with this since we have kill and
>> signals and other mechanisms already existing for most of this
>> the duplication at the very least seems silly.
>
> But you don't really.  If I want to kill all processes in a child
> container, I don't have an easy way to list only the processes in the
> child container using, say, ps.  Those processes are just lumped in with
> my own, and with those from all my other child containers.

True.  Mostly because that is the interface that makes the most
sense most of the time.

> So we'd end up looping over all pids, checking their ->container, then
> killing them, and hoping that nothing funky happens meanwhile like that
> process dies and pids wrap around while i'm sleeping (ok, unlikely, but
> not impossible).
>
> I'm not saying I'm hung up on doing it with an rm /container_ns/vs1.  If
> the only use for the ns container subsystem ends up being to tie
> resource management to containers, I'll be very happy.

We've got to get a better name for those things....

Regardless one of the requirements of the pid namespace is that we have
a process grouping of the entire namespace that kill(-1 can signal
and there is no reason not to have that process grouping available on
the outside of the pid namespace as well.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> 
> >> You miss an issue here.  One of the dangers of enter is leaking
> >> capabilities into a contained set of processes.   Once you show up in
> >
> > Good point.  As wrong as it feels to me to use ptrace for this, the
> > advantage is that none of my task attributes leak into the target
> > namespace, and that's a very good thing.
> >
> > I do wonder how you specify what the forced clone should run.
> > Presumably you want to run something not in the target container.
> > I suppose we can pass the fd over a socket or something.
> 
> Yes.  At least in the case without a network namespace I can setup
> a unix domain socket and pass file descriptors around.  I think my solution
> to the network namespace case was to just setup a unix domain socket in
> the parent namespace and leave it open in init.  Not a real solution :(

How about we solve both this and the general ugliness of using ptrace
with a new

	hijack_and_clone(struct task_struct *tsk, int fd)

Which takes tsk, clones it, and execs the contents of fd?

-serge
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> How about we solve both this and the general ugliness of using ptrace
> with a new
>
> 	hijack_and_clone(struct task_struct *tsk, int fd)
>
> Which takes tsk, clones it, and execs the contents of fd?

That is what roughly what I was thinking.  Although that is an ugly
beast to implement.  Getting stdin and stdout should still be doable
using a tty.  Getting the semantics and the implementation right is
a tough challenge.  

After thinking about it a normal exec (unless you want your binary to
come from inside the namespace) is nearly useless because it requires
a static binary.  With glibc not actually going static, static
binaries are nearly impossible to write.  Although that might be
a good argument for minimalism, and security.

The really important use of the ptrace case is that it works using
existing mechanisms without leaks.  So it is very useful yardstick.

The other important yardstick is arranging it so that when you login
to a machine all of the user code runs in your target environment.
How you get there is irrelevant.

One of the cases I have been worrying about in looking at the
semantics of enter is what do you do with the parent pid.  Supporting
ptrace from outside the pid namespace of a process inside a pid
namespace requires supporting a parent process outside of the pid
namespace for processes other than init.

I'm not convinced setting up a non-ptrace parent that is outside the
pid namespace makes sense, but it looks like the mechanism is going
to be there.  If we did support a foreign parent it would go a long
way towards supporting the login and be redirected into a container
case, as well as Herbert's pid namespace without an init case.

I have finally worked through all of the reasonable irq handling
alternatives and unless something goes wrong will I will be submitting
that code tomorrow.  I really want to pull some pid namespace patches
together so we can bring those into the conversation but I don't
think I will be able to get there before I head out first of March
to Nebraska to spend some time with my brother.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

On 2/22/07, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> The really important use of the ptrace case is that it works using
> existing mechanisms without leaks.  So it is very useful yardstick.
>
> The other important yardstick is arranging it so that when you login
> to a machine all of the user code runs in your target environment.
> How you get there is irrelevant.
>
> One of the cases I have been worrying about in looking at the
> semantics of enter is what do you do with the parent pid.  Supporting
> ptrace from outside the pid namespace of a process inside a pid
> namespace requires supporting a parent process outside of the pid
> namespace for processes other than init.
>

When I implemented a virtual server solution at my previous job, we
solved the problem of leaking capabilities into the virtualized
environment by allowing a process to enter the virtual server in a
"privileged" mode, in which it didn't appear in the virtualized /proc,
and hence none of its resources were accessible to processes in the
VS. Children of a privileged process were by default regular members
of the virtual server.

With the nsproxy model, maybe you could implement that by having two
pid namespaces. When you create the VS, you create an entire set of
new namespaces; then before forking init you create a new pid_ns. So
by entering the outer nsproxy you'd get access to the same environment
that the VS sees, but your process wouldn't be visible to processes in
the VS. If you wanted to create a regular process, you'd just enter
the inner pid_ns too. I think that doing the appropriate process
"sanitization" to avoid leaking capabilities would be easier from the
"twilight zone" intermediate nsproxy than from the machine top-level.

Paul
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

On 2/22/07, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Now it is at least worth investigating if you can leak things if you don't
> enter the pid namespace.  If you can not leak things that potentially
> simplifies big chunks of the problem, and we probably don't need the
> intermediate pid namespace, of your suggestion.

If you're happy to have your partially-entered process be viewing the
system pid namespace rather than (container pid namespace) + (self)
then yes, you don't need the intermediate namespace.

Paul
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

"Paul Menage" <menage@google.com> writes:

> When I implemented a virtual server solution at my previous job, we
> solved the problem of leaking capabilities into the virtualized
> environment by allowing a process to enter the virtual server in a
> "privileged" mode, in which it didn't appear in the virtualized /proc,
> and hence none of its resources were accessible to processes in the
> VS. Children of a privileged process were by default regular members
> of the virtual server.
>
> With the nsproxy model, maybe you could implement that by having two
> pid namespaces. When you create the VS, you create an entire set of
> new namespaces; then before forking init you create a new pid_ns. So
> by entering the outer nsproxy you'd get access to the same environment
> that the VS sees, but your process wouldn't be visible to processes in
> the VS. If you wanted to create a regular process, you'd just enter
> the inner pid_ns too. I think that doing the appropriate process
> "sanitization" to avoid leaking capabilities would be easier from the
> "twilight zone" intermediate nsproxy than from the machine top-level.

And this is why I keep coming back to ptrace.   It doesn't leak and
it does seem to get the job done.  If you have to because you can
run system calls you can implement exec by hand.  ptrace also allows
many of the intermediate enter scenarios.

ptrace is clumsy and there does have to be a better way but until I find
something that isn't clumsy I will stick with ptrace.

Now it is at least worth investigating if you can leak things if you don't
enter the pid namespace.  If you can not leak things that potentially
simplifies big chunks of the problem, and we probably don't need the
intermediate pid namespace, of your suggestion.

Still I'm drawn back to the simplicity of the proof of the ptrace
situation.


On another note Serge there is another possibility for dealing with
fs_struct.  You can chdir(/proc/<someotherpidinthenamespace>/) and
get your working directory changed after the unshare.

All I know for certain is that it really sucks designing things with
new semantics that interact closely with all of the old existing
rules.  It is really easy to come up with something that doesn't
work well, or is a major hazard when people use it in unexpected ways.

So I'm generally in favor of not rushing things and taking the big
things like enter in as small a step as we can.  Because whatever
we merge we will likely need to be supported for the rest our lives.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Herbert Poetzl <herbert@13thfloor.at> writes:

>
> sorry for the late answer, I almost missed that one ...
>
> yes, that sounds like an acceptable alternative, but 
> it might give some interesting issues with references
> to devices ... for example:
>
> you mount a filesystem inside a namespace, so that
> only the guest will see it (in theory) now you somehow
> show that in the namespace copy too (on the host system)
> and if some task decides to go camping there (cd into
> that) it might keep the guest from unmounting that 
> device without ever knowing why ... or do you have some
> smart solution to that?

lazy unmount.

>> net+pid+uts
>> 
>> Not sure about uts, but I'm pretty sure the vserver folks want the 
>> ability to enter another existing network namespace, and both vserver 
>> and openvz have asked for the ability to enter pid namespaces.
>
> yes, definitely, pid and network namespaces have to
> be accessible somehow, most administrative work is
> done this way, when the administrator also maintains
> the guests (i.e. doesn't want to bother accessing the
> guest via special console/ssh/logon/whatever)
>
>> The pid namespaces could be solved by always generating as many pids for
>> a process as it has parent pid_namespaces.  So if I'm in /vserver1, with
>> one pid_namespace above me, not only my init process has an entry in the
>> root pid_namespace (as I think has been suggested), but all my children
>> will also continue to have pids in the root pid_namespace.
>
> yep, sounds okay to me ...
> note, our lightweight guests do not have an init
> process, which is perfectly fine with the above, as
> long as the init process is not considered a special
> handle to the pid namespace :)
>
>> Or, if it is ok for the pid namespace operations to be as coarse as
>> "kill all processes in /vserver1", then that was going to be implemented
>> using the namespace container subsystem as:
>> 
>> 	rm -rf /container_ns/vserver1
>
> that is definitely something you do not want to make
> the general signalling solution, because typically
> we have the following scenarios:
>
>  - init less (lightweight) guest
>    + a bunch of shutdown scripts are executed
>    + term/kill is sent to the processes
>    + the context is disposed 
>
>  - init based guest
>    + a signal is sent to init
>    + init executes the shutdown and kills off
>      the 'other' processes
>    + init finally calls reboot/halt
>    + init and the context are disposed

I have seen the same thing invented in a different context so this
sounds like a common pattern.

>> Any other (a) requirements, (b) ideas for alternate pid and network
>> ns management without allowing namespace enters?
>
> entering the spaces seems most natural and quite
> essential to me, especially for administration and
> debugging purposes ...

Yes.  But how you implement the enter need not be modifying
the namespace pointer in a task_struct/nsproxy.  You can get the same
user effect in other ways, which are potentially more secure.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

On Sat, 2007-03-10 at 02:36 +0100, Herbert Poetzl wrote:
> you mount a filesystem inside a namespace, so that
> only the guest will see it (in theory) now you somehow
> show that in the namespace copy too (on the host system)
> and if some task decides to go camping there (cd into
> that) it might keep the guest from unmounting that 
> device without ever knowing why ... or do you have some
> smart solution to that?

What is the actual issue here?  That an underlying device might still be
in use, or that the container user has a directory they don't want
mounted sitting in their fs tree?

-- Dave

_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Quoting Eric W. Biederman (ebiederm@xmission.com):
> Herbert Poetzl <herbert@13thfloor.at> writes:
> 
> >
> > sorry for the late answer, I almost missed that one ...
> >
> > yes, that sounds like an acceptable alternative, but 
> > it might give some interesting issues with references
> > to devices ... for example:
> >
> > you mount a filesystem inside a namespace, so that
> > only the guest will see it (in theory) now you somehow
> > show that in the namespace copy too (on the host system)
> > and if some task decides to go camping there (cd into
> > that) it might keep the guest from unmounting that 
> > device without ever knowing why ... or do you have some
> > smart solution to that?
> 
> lazy unmount.
> 
> >> net+pid+uts
> >> 
> >> Not sure about uts, but I'm pretty sure the vserver folks want the 
> >> ability to enter another existing network namespace, and both vserver 
> >> and openvz have asked for the ability to enter pid namespaces.
> >
> > yes, definitely, pid and network namespaces have to
> > be accessible somehow, most administrative work is
> > done this way, when the administrator also maintains
> > the guests (i.e. doesn't want to bother accessing the
> > guest via special console/ssh/logon/whatever)
> >
> >> The pid namespaces could be solved by always generating as many pids for
> >> a process as it has parent pid_namespaces.  So if I'm in /vserver1, with
> >> one pid_namespace above me, not only my init process has an entry in the
> >> root pid_namespace (as I think has been suggested), but all my children
> >> will also continue to have pids in the root pid_namespace.
> >
> > yep, sounds okay to me ...
> > note, our lightweight guests do not have an init
> > process, which is perfectly fine with the above, as
> > long as the init process is not considered a special
> > handle to the pid namespace :)
> >
> >> Or, if it is ok for the pid namespace operations to be as coarse as
> >> "kill all processes in /vserver1", then that was going to be implemented
> >> using the namespace container subsystem as:
> >> 
> >> 	rm -rf /container_ns/vserver1
> >
> > that is definitely something you do not want to make
> > the general signalling solution, because typically
> > we have the following scenarios:
> >
> >  - init less (lightweight) guest
> >    + a bunch of shutdown scripts are executed
> >    + term/kill is sent to the processes
> >    + the context is disposed 
> >
> >  - init based guest
> >    + a signal is sent to init
> >    + init executes the shutdown and kills off
> >      the 'other' processes
> >    + init finally calls reboot/halt
> >    + init and the context are disposed
> 
> I have seen the same thing invented in a different context so this
> sounds like a common pattern.
> 
> >> Any other (a) requirements, (b) ideas for alternate pid and network
> >> ns management without allowing namespace enters?
> >
> > entering the spaces seems most natural and quite
> > essential to me, especially for administration and
> > debugging purposes ...
> 
> Yes.  But how you implement the enter need not be modifying
> the namespace pointer in a task_struct/nsproxy.  You can get the same
> user effect in other ways, which are potentially more secure.

Thanks guys.

I think the main people interested in the namespace entering will be
Herbert, Kirill, and Cedric seems interested.  Is someone planning to
try doing a non-enter virtual server management implementation, to see
what shortcomings there are?  Or is it more likely that you'll keep
using your own namespace entering patches for a long time to come?

(The latter seems likely given that you still need to patch anyway at
the moment, so continuing to use your existing work is cheaper for you.
So i expect that experimenting with other approaches will be up to
someone doing it purely out of curiosity)

-serge
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

On Mon, Mar 12, 2007 at 10:00:34AM -0700, Dave Hansen wrote:
> On Sat, 2007-03-10 at 02:36 +0100, Herbert Poetzl wrote:
> > you mount a filesystem inside a namespace, so that
> > only the guest will see it (in theory) now you somehow
> > show that in the namespace copy too (on the host system)
> > and if some task decides to go camping there (cd into
> > that) it might keep the guest from unmounting that 
> > device without ever knowing why ... or do you have some
> > smart solution to that?
> 
> What is the actual issue here? 

> That an underlying device might still be in use, 

yes, after thinking about it, it might not be such
an issue after all, because in 95% of all cases,
this is only a problem for the host admin, and can
be prevented by simply _not_ doing that ...

> or that the container user has a directory they don't want
> mounted sitting in their fs tree?

that shouldn't actually happen no? if the guest
is allowed to do unmounts, then the mount can be
removed from inside, if not, then the mount has to
be part of the guest configuration, so no problem
there IMHO

thanks,
Herbert

> -- Dave
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers