[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] I am working on seccomp integration into docker for project Atomic.



On 10/28/2014 11:40 AM, SGhosh wrote:
> On 10/28/2014 10:14 AM, Daniel J Walsh wrote:
>> On 10/28/2014 09:33 AM, SGhosh wrote:
>>> On 10/28/2014 08:47 AM, Jon Stanley wrote:
>>>> On Tue, Oct 28, 2014 at 7:59 AM, Daniel J Walsh<dwalsh redhat com>
>>>> wrote:
>>>>
>>>>>> syscalls, by default.  On an X86_64 system x32 and i686 syscalls
>>>>> will be
>>>>>> eliminated.
>>>> This seems problematic in the fact that you couldn't then run a 32-bit
>>>> application in a container, unless I'm missing something.
>>>>
>>> Dan
>>>
>>> - would it be possible to have runtime instantiated seccomp profiles?
>>> eg. decide early on whether the i686 syscalls will be allowed or not?
>>>
>>> additive profiles like tuned?
>>>
>>> -subhendu
>> Not sure what that means.  Adding i686 support would require you to do
>> something like
>>
>> docker run --security-opt seccomp:add_arch:i686 ...
> Wondering how to tie a config file of pre-defined options that can be
> invoked by the cli
>>
>> I would love it if we could get to the point where the packager of the
>> app could describe the requirements of the application in the json meta
>> data.  But I am not sure if docker upstream would take this kind of
>> patch.
>>
>> Sort of a meta { "requires": "seccomp:add_arch:i686" }
>>
>> Doing this for capabilities, seccomp, SELinux types, would be nice, as
>> well as specifying which volume mounts need to be mounted into the
>> container.
> Might be able to get this via k8e yaml definition for pods if docker
> upstream is stuck on META.
> It might be easier to have in K8e as the yaml files are read before
> invoking the docker cli.
>
> -sg
>
Yes although all that k8e could do is execute the correct docker
run/create command.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]