On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
> > A related issue which is NOT FIXED HERE is limits for all resources
> > available for containerized pseudo roots. E.g. I succeeded creating
> > thousands of veth network devices without problems by a non-root user,
> > there seems
On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
A related issue which is NOT FIXED HERE is limits for all resources
available for containerized pseudo roots. E.g. I succeeded creating
thousands of veth network devices without problems by a non-root user,
there seems no limit
On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
> Vasily Kulikov writes:
>
> > Currently there is completely no limiting in number of user namespaces
> > created by unprivileged users. One can freely create thousands of
> > user_ns'es and exhaust kernel memory without even bumping
On Fri, Dec 28, 2012 at 08:05:32PM -0800, Eric W. Biederman wrote:
> Yes. Gcc can't turn a tail call into a jump in even the most basic
> cases apparently.
What. The. Fuck?
You have introduced unlimited recursion on kernel stack. OK, it's
unpleasant, but it can happen to anybody. But then
Vasily Kulikov writes:
> Currently there is completely no limiting in number of user namespaces
> created by unprivileged users. One can freely create thousands of
> user_ns'es and exhaust kernel memory without even bumping in
> RLIMIT_NPROC or similar.
First for a proper sense of scale it
On Fri, Dec 28, 2012 at 11:04:35PM +0400, Vasily Kulikov wrote:
> > I'm sorry, but this is not a solution. Kernel is not x86-only; there are
> > architectures with far bigger minimal stack frame size. E.g. on sparc64
> > every fucking stack frame is at least 176 bytes. So your 100 calls deep
>
On Fri, Dec 28, 2012 at 18:43 +, Al Viro wrote:
> On Fri, Dec 28, 2012 at 09:56:27PM +0400, Vasily Kulikov wrote:
> > The included patch is a basic fix for both or them. Both values are
> > hardcoded here to 100 max depth and 1000 max in total. I'm not sure how
> > better to make them
On Fri, Dec 28, 2012 at 09:56:27PM +0400, Vasily Kulikov wrote:
> The included patch is a basic fix for both or them. Both values are
> hardcoded here to 100 max depth and 1000 max in total. I'm not sure how
> better to make them configurable. Looks like it needs some sysctl value
> like
Currently there is completely no limiting in number of user namespaces
created by unprivileged users. One can freely create thousands of
user_ns'es and exhaust kernel memory without even bumping in
RLIMIT_NPROC or similar.
Even more -- it allows user to overflow kernel stack theoretically
Currently there is completely no limiting in number of user namespaces
created by unprivileged users. One can freely create thousands of
user_ns'es and exhaust kernel memory without even bumping in
RLIMIT_NPROC or similar.
Even more -- it allows user to overflow kernel stack theoretically
On Fri, Dec 28, 2012 at 09:56:27PM +0400, Vasily Kulikov wrote:
The included patch is a basic fix for both or them. Both values are
hardcoded here to 100 max depth and 1000 max in total. I'm not sure how
better to make them configurable. Looks like it needs some sysctl value
like
On Fri, Dec 28, 2012 at 18:43 +, Al Viro wrote:
On Fri, Dec 28, 2012 at 09:56:27PM +0400, Vasily Kulikov wrote:
The included patch is a basic fix for both or them. Both values are
hardcoded here to 100 max depth and 1000 max in total. I'm not sure how
better to make them configurable.
On Fri, Dec 28, 2012 at 11:04:35PM +0400, Vasily Kulikov wrote:
I'm sorry, but this is not a solution. Kernel is not x86-only; there are
architectures with far bigger minimal stack frame size. E.g. on sparc64
every fucking stack frame is at least 176 bytes. So your 100 calls deep
call
Vasily Kulikov seg...@openwall.com writes:
Currently there is completely no limiting in number of user namespaces
created by unprivileged users. One can freely create thousands of
user_ns'es and exhaust kernel memory without even bumping in
RLIMIT_NPROC or similar.
First for a proper sense
On Fri, Dec 28, 2012 at 08:05:32PM -0800, Eric W. Biederman wrote:
Yes. Gcc can't turn a tail call into a jump in even the most basic
cases apparently.
What. The. Fuck?
You have introduced unlimited recursion on kernel stack. OK, it's
unpleasant, but it can happen to anybody. But then
On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
Vasily Kulikov seg...@openwall.com writes:
Currently there is completely no limiting in number of user namespaces
created by unprivileged users. One can freely create thousands of
user_ns'es and exhaust kernel memory without
16 matches
Mail list logo
