Re: [RFC] [PATCH 00/13] Introduce task_pid api

[ebiederm@xmission.com (Eric W. Biederman)]

Dave Hansen <haveblue@us.ibm.com> writes:

> On Wed, 2005-12-07 at 12:19 -0700, Eric W. Biederman wrote:
>> >> Another question is how do your pid spaces nest.
>> >
>> > They don't, and thankfully there is anybody asking for it.  It adds
>> > loads of complexity, and nobody apparently needs it.
>> 
>> So only very special pids can generate a pidspace.  That will
>> tend to reduce the generality of the solution.  What do you do
>> if I am running your code in a vserver?
>
> I don't think it would be a good idea to stack these containers within
> vservers, either.  vserver uses different pidspaces, and will use the
> same infrastructure.  The only difference is that they only have a very
> small change to the different pidspaces for init.

Well that depends on the implementation.  The first concern with
the implementation is of course maintainability.

But beyond that a general test to see if you have done a good
job of virtualizing something is to see if you can recurse.

One of my wish list items would be to run my things like my
web browser in a container with only access to a subset of
the things I can normally access.  That way I could be less
concerned about the latest browser security bug.

Although I do expect that just like private namespaces it will
take a while to figure out how to allow non-privileged access
to these kinds of powerful concepts.

In the bsdjail paper the point is made that as systems grow
more complex creating minimal privilege containers is easy
and simple compared to what it takes to get a complex system
up and going today.  (I expressed that badly)  

And then of course there is the other pipe dream if you can
consider the whole system in a container then you can implement
the equivalent of swsuspend by checkpointing the top level
container.

At least this should solve the classic complaint about job
control.  That it wasn't transparent to processes.

>> >> Who do you report as the source of your signal.  
>> >
>> > I've never dealt with signal enough from userspace to give you a good
>> > answer.  Can you explain the mechanics of how you would go about doing
>> > this?
>> 
>> Look at siginfo_t si_pid....
>
> Are those things that are exported outside of the kernel?  It's not
> immediately obvious.

Sorry do a man sigaction.  Basically the signal handler
needs to be configured with SA_SIGINFO but it should get
that information.  

I believe you have to 

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/