Thanks Chas
On the isolation policy I agree - different threat scenarios have different
solutions. Our current use of AFS In this sense is really a access isolation
issue (got access to one container doesn’t get you access to other AFS tokens)
and cost reduction (running multiple containers in
I will submit something later today for it and hopefully we can get it
approved.
While mounting /proc and /sys as read only does provide more isolation,
it obviously doesn't provide complete isolation. I don't think anyone
would be surprised by that though. However, OpenAFS should really be
Jeffrey
I'm not certain I agree with the security logic. It rather reduces some of the
deployment use-cases (and hence
the potential economic value).
There are several scenarios where you want the security information _inside_
the ‘container', this makes the
container (say a VM of some kind)
On 12/1/2015 10:16 AM, Neil Davies wrote:
> Jeffrey
>
> I'm not certain I agree with the security logic. It rather reduces some of
> the deployment use-cases (and hence
> the potential economic value).
>
> There are several scenarios where you want the security information _inside_
> the
Chas
Didn’t get the time to get around to it yesterday, but did today.
I can confirm that changing the appropriate line in src/sys/glue.c to open
/proc/fs/openafs/afs_ioctl RDONLY works.
I used the current ubuntu sources (1.6.7 + PATCHES), built a new version with
the patch and installed it
Chas
This sounds like a plan!
I've got a few things to do first thing today, but I'll try and get round to
putting up an appropriate test system and trying this later today.
Neil
On 28 Nov 2015, at 22:44, Charles (Chas) Williams <3ch...@gmail.com> wrote:
> Strangely, I don't see a reason for
I can confirm that this sis the problem
There was a change in docker 1.2.1 (a CVE related fix) that now forces /proc/fs
to be mounted read-only
use of the --privileged argument to docker run does allow openafs to run ok,
but only at the cost of loosing
all of the container isolation!
I spent
On 11/28/2015 4:19 PM, Neil Davies wrote:
> I can confirm that this sis the problem
>
> There was a change in docker 1.2.1 (a CVE related fix) that now forces
> /proc/fs to be mounted read-only
>
> use of the --privileged argument to docker run does allow openafs to run ok,
> but only at the
Strangely, I don't see a reason for this file to opened read/write by
the OpenAFS utilities. We only use ioctl() and I believe that only
needs O_RDONLY. Change src/sys/glue.c to be O_RDONLY instead of O_RDWR
when it opens PROC_SYSCALL_FNAME.
I don't happen to have a test system right now, or I
On Nov 27, 2015, at 13:42 , Neil Davies wrote:
> After this upgrade I am no longer able, in the container, able to push tokens
> into the kernel - it gives a pioctl.
Is there any chance you can run an strace on this?
I believe that /proc was changed to read-only at some point for docker
Hi Neil,
thanks for the report, but I'm afraid I'm not getting it.
On Nov 27, 2015, at 13:42 , Neil Davies wrote:
> I’ve been successfully running containers for several years.
> initially using lxc and now docker, inside machines where there was:
> an outer AFS service;
> accessed by
On 11/27/2015 7:42 AM, Neil Davies wrote:
> Hi
>
> I’ve been successfully running containers for several years.
> initially using lxc and now docker, inside machines where there was:
>an outer AFS service;
>accessed by the processes inside the container.
>
> It worked fine (we are
12 matches
Mail list logo
