On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
> On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov wrote:
>
> > >
> > > Or will we? What happens if we later decide that some additional field
> > > needs to be added? Do we version the interface? Add a new prctl()
> > > mode?
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov wrote:
> >
> > Or will we? What happens if we later decide that some additional field
> > needs to be added? Do we version the interface? Add a new prctl()
> > mode? Let's cook up a plan for that and at least add to changelog?
>
> I don't
On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
> > >
> > > But it's a bit hacky. Can anyone think of anything smarter?
> >
> > Looks good to me and not that hacky actually.
>
> Hacky :( I guess it's pretty safe because this is a userspace-visible
> structure so we'll never be
On Fri, 22 Aug 2014 10:32:42 +0400 Cyrill Gorcunov wrote:
> > > + error |= __prctl_check_addr_space(start_code);
> > > + error |= __prctl_check_addr_space(end_code);
> > > + error |= __prctl_check_addr_space(start_data);
> > > + error |= __prctl_check_addr_space(end_data);
> > > + error |=
On Thu, Aug 21, 2014 at 03:51:15PM -0700, Andrew Morton wrote:
...
> >
> > Still note that updating exe-file link now doesn't require sys-resource
> > capability anymore, after all there is no much profit in preventing setup
> > own file link (there are a number of ways to execute own code --
On Thu, Aug 21, 2014 at 03:51:15PM -0700, Andrew Morton wrote:
...
Still note that updating exe-file link now doesn't require sys-resource
capability anymore, after all there is no much profit in preventing setup
own file link (there are a number of ways to execute own code -- ptrace,
On Fri, 22 Aug 2014 10:32:42 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
+ error |= __prctl_check_addr_space(start_code);
+ error |= __prctl_check_addr_space(end_code);
+ error |= __prctl_check_addr_space(start_data);
+ error |= __prctl_check_addr_space(end_data);
+ error |=
On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
But it's a bit hacky. Can anyone think of anything smarter?
Looks good to me and not that hacky actually.
Hacky :( I guess it's pretty safe because this is a userspace-visible
structure so we'll never be changing it.
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Or will we? What happens if we later decide that some additional field
needs to be added? Do we version the interface? Add a new prctl()
mode? Let's cook up a plan for that and at least add to changelog?
On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Or will we? What happens if we later decide that some additional field
needs to be added? Do we version the interface? Add a new prctl()
On Mon, 04 Aug 2014 21:22:59 +0400 Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is created
On Mon, 04 Aug 2014 21:22:59 +0400 Cyrill Gorcunov gorcu...@openvz.org wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created
On Tue, Aug 05, 2014 at 12:08:53PM +0400, Andrew Vagin wrote:
> >
> > Signed-off-by: Cyrill Gorcunov
> > Cc: Kees Cook
> > Cc: Tejun Heo
> > Cc: Andrew Morton
> > Cc: Andrew Vagin
>
> Acked-by: Andrew Vagin
>
> I have tested this patch with criu. Everything work as expected.
Thanks
On Mon, Aug 04, 2014 at 09:22:59PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is created
On Mon, Aug 04, 2014 at 09:22:59PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created
On Tue, Aug 05, 2014 at 12:08:53PM +0400, Andrew Vagin wrote:
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava...@openvz.org
Acked-by: Andrew Vagin
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is created capable(CAP_SYS_RESOURCE) no longer
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer
20 matches
Mail list logo
