Use oci-seccomp-gen library for adding seccomp configurations #128
Conversation
|
@mrunalp Not sure how to fix this error. |
|
@grantseltzer Your commit is missing a Signed-off-by. |
|
ae08020 has recursive Godeps :p. I'm not sure if that's an expected
thing, but 103 vendored files and 10k lines is a lot to pull in for
this change. Maybe we can get a smaller library with the bits we need
without Manhattan → runc → docker → libtrust and similar dependency
chains?
|
| @@ -27,7 +29,6 @@ var generateFlags = []cli.Flag{ | |||
| cli.StringSliceFlag{Name: "groups", Usage: "supplementary groups for the process"}, | |||
| cli.StringSliceFlag{Name: "cap-add", Usage: "add capabilities"}, | |||
| cli.StringSliceFlag{Name: "cap-drop", Usage: "drop capabilities"}, | |||
| cli.StringFlag{Name: "cgroup", Usage: "cgroup namespace"}, | |||
There was a problem hiding this comment.
You probably didn't intend to remove this (it landed in #122). Maybe a busted rebase?
|
@wking Not sure what's causing that godeps recursive chain. Do you know why that's happening? |
|
On Fri, Jul 01, 2016 at 04:52:03PM -0700, Grant Seltzer Richman wrote:
I'm not familiar with Godeps, but if it is just based on Git clones |
Yea, the issue is that I have the library ociseccompgen and the tool manhattan in the same git repo. I didn't expect For the sake of this this PR at least I can do that along with the fixing spacing and re-adding cgroup flag that I accidentally removed. Thoughts? |
|
On Fri, Jul 01, 2016 at 05:12:30PM -0700, Grant Seltzer Richman wrote:
I don't know enough about Godeps to know what the right fix is ;). |
| @@ -9,6 +9,8 @@ import ( | |||
| "strconv" | |||
| "strings" | |||
|
|
|||
| seccomp "github.com/grantseltzer/Manhattan/oci-seccomp-gen" | |||
|
|
|||
|
@grantseltzer I follow this instruction to update your dependency, it works, no extra 'Godeps' added. I'm not sure if it also helps in your environment. |
| Action: "SCMP_ACT_ALLOW", | ||
| } | ||
| secc.Syscalls = append(secc.Syscalls, sysCall) | ||
| err = seccomp.ParseSyscallFlag("trace", seccompTrace, &secc) |
There was a problem hiding this comment.
maybe put all the five ParseSyscallFlag functions to one loop?
|
Hi @grantseltzer , @mrunalp @wking @Mashimiao what do you think about this? The code struct could look like this: |
|
I'm +1k to include that library directly in ocitools and have Manhattan or ocitools itself to manage and generate seccomp profiles or OCI configs |
|
On Mon, Jul 04, 2016 at 02:22:52AM -0700, 梁辰晔 (Liang Chenye) wrote:
Is ‘pkg’ more idiomatic than ‘lib’? I don't read enough Go to know,
Why keep this executable separate? Isn't this PR just rolling it into |
|
No pkg nor lib, just the name of the library is go idiomatic |
|
+1 also on having the main tool work with the library directly instead of creating a contrib dir with binaries in there. So just: ./seccomp And code from that used in the main ocitools |
|
I like the idea of having the ociseccompgen be part of the ocitools library, that makes a lot of sense. Just to clarify, are we in disagreement that seccomp should be a flag for the Manhattan is fully functioning for generated just the seccomp configurations: https://github.com/GrantSeltzer/Manhattan |
|
Could add a flag --seccomp-only to ocitools generate Sent from my iPhone
|
|
I'm +1 for this. |
|
OK, +1 for |
|
Alright, I'm working on the following points:
Should this be it's own PR (this would be closed) or squashed with the commit for this one? |
|
On Tue, Jul 05, 2016 at 12:23:18PM -0700, Grant Seltzer Richman wrote:
What is the use-case for this? Can we accomplish the same thing by $ ocitools generate … | jq .linux.seccomp |
|
The use case is for use with other tools like docker that you can pass a seccomp configuration file to a container or (soon) the daemon. And yes piping into jq would do the same thing, But I think this would be more user friendly and feel less like a hack. |
|
On Tue, Jul 05, 2016 at 12:39:19PM -0700, Grant Seltzer Richman wrote:
I'm just not sure how generically we should scope the solution. I'd And I think using jq for JSON dicing is using the proper (already And regardless of how we address this, always writing to config.json |
|
I think having a flag for I'm not sure what other configurations can be independently used besides seccomp but I think the |
This makes it easier to post-process output before writing it to disk. For example, you may want to make adjustments with jq, or write part of the configuration to a different file for consumption by non-OCI tools [1]. [1]: opencontainers#128 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
| @@ -139,12 +145,13 @@ func New() Generator { | |||
| Devices: []rspec.Device{}, | |||
| }, | |||
| } | |||
| return Generator{&spec} | |||
| return Generator{&spec, &ExportOptions{}} | |||
There was a problem hiding this comment.
You don't need these now that you've dropped it from Generator.
There was a problem hiding this comment.
Actually, it looks like you forgot to drop it from Generator ;).
There was a problem hiding this comment.
fixing now :P
|
I'd like to open a fresh branch/PR if it's alright, the commit's for this one have gotten unmanageable because of multiple merge commits in the time it's been sitting. Besides the fail for the non-dco, everything seems good to me. Let me know whenever you're ready to look at this, Mrunal. |
|
On Tue, Jul 26, 2016 at 12:33:19PM -0700, Grant Seltzer Richman wrote:
No need for a new PR. Once you have a squashed commit, just |
I believe the last commit is rebased on top of the current ocitools master branch |
|
On Tue, Jul 26, 2016 at 01:01:39PM -0700, Antonio Murdaca wrote:
I've rebased it backwards with: $ git rebase --onto 564b30e HEAD^ After resolving some conflicts in code you'd deleted (but which had $ diff -u <(git show --color=always cbd3a2e) <(git show --color=always 69526b9) If that looks right to you, I'd like to see 69526b9 pushed to this PR |
sorry, can't be just wait to land this in master and cherry-pick for the release? or create another pr for the release branch? it's so confusing for everyone like this, why are you rushing? |
|
@grantseltzer will of course take care of opening a PR against the release branch once this is finished and afaict this isn't yet fully reviewed and lgtm'ed |
|
On Tue, Jul 26, 2016 at 01:13:53PM -0700, Antonio Murdaca wrote:
That's the “The alternative is …” route above. I'd rather not
This is how lots of projects work. For example see Git's section on At some point ocitools is (I think) going to have to support multiple |
|
On Tue, Jul 26, 2016 at 01:14:36PM -0700, Antonio Murdaca wrote:
Sounds good, and it is good to wait until the branch is reviewed and |
|
I think the API should be easy to use just like rest of generate. The command line option parsing should be left to integration with the cmd. |
|
@mrunalp How's that? I created a seccomp generator in the same way the generate library has. |
|
@grantseltzer No, this doesn't help. User shouldn't have to deal with two different generators when trying to generate a config. You could create a seccomp generator API and then use it from the regular generate API. The generate API should be simple and comprehensive. For e.g. gen := generate.New()
gen.SetSeccompDefault(..) // These calls could use your own seccomp API behind the scenes.
gen.AddSeccompErrno(..)
gen.AddSeccompKill(..)
gen.SetRootfs(..)
gen.AddCapability(..)
gen.SaveToFile(..) |
|
Just to clarify do you want all of the command line parsing done in the main package? |
|
@grantseltzer Yes, it shouldn't be in the API. |
|
I think the check is failing because of vendoring, looking into it now, it's working locally |
Signed-off-by: Grantseltzer <grantseltzer@gmail.com>
|
Can you open a new PR with your commit cherry picked to see if we can make the travis issue go away? |
|
On Wed, Jul 27, 2016 at 04:43:03PM -0700, Mrunal Patel wrote:
New PR should not matter and this PR has already had its history |
|
@wking It builds fine locally. |
|
@wking If you actually check the code you can see that it has been fixed but travis is not finding the correct commit. |
|
On Wed, Jul 27, 2016 at 04:53:37PM -0700, Grant Seltzer Richman wrote:
Ah, in that case pushing an amended commit (to bump the commit |
|
Actually, here's the merge commit Travis is testing not using a |
|
On Wed, Jul 27, 2016 at 05:56:21PM -0700, Grant Seltzer Richman wrote: So we should close this one? |
|
Yup @mrunalp |
|
On Thu, Jul 28, 2016 at 07:48:10PM -0700, Grant Seltzer Richman wrote:
@grantseltzer, as the PR author, you should be able to close it too. |
I added functionality to specify syscalls and their arguments for all actions. Also changed default action and archs flags to ociseccompgen library.
Now we can do things like:
ocitools generate --seccomp-errno clone,write --seccomp-trace getcwd --seccomp-trap umount:0:1:2:NEThe behavior mimics that of: https://github.com/GrantSeltzer/Manhattan
Also updated man page to reflect this change.