add bundle validate as sub-command #20
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: liangchenye <liangchenye@huawei.com>
|
Thanks for the PR. I am on vacation and will be slow in responding till next week. |
Signed-off-by: liangchenye <liangchenye@huawei.com>
Signed-off-by: liangchenye <liangchenye@huawei.com>
|
@mrunalp bundle validate is updated to 0.3.0 |
|
Build failure as you need to bump up the spec to 0.3.0 in Godeps. Thanks! |
Signed-off-by: liangchenye <liangchenye@huawei.com>
|
Godeps updated. The config.json generated by ocitools could not pass the bundle validation, since three security fields are not noted as 'optional', I submit a PR here (opencontainers/runtime-spec#325) |
|
Opps, the codes under cmd directory should also need to be changed. |
Signed-off-by: liangchenye <liangchenye@huawei.com>
|
cmd updated. |
|
Can you update the deps to pickup the change where selinuxlabel and apparmor got moved to proces? |
|
Also, we need to make seccomp optional in the spec. Otherwise this seems to be working well. |
|
I have created PR for seccomp opencontainers/runtime-spec#333 |
|
I think we can merge this for now and fix up things in follow up PRs. Thanks! LGTM |
mrunalp
pushed a commit
that referenced
this pull request
Mar 8, 2016
add bundle validate as sub-command
|
Yes, I'll update all of the selinuxlabel/apparmor/seccomp Godeps once |
wking
added a commit
to wking/ocitools-v2
that referenced
this pull request
May 20, 2016
These landed as CheckMounts in 647e355 (bundle validate update to 0.3.0, 2016-02-23, opencontainers#20), but both checks are too strict. The first (destination exists in the rootfs) errors on valid cases like: "mounts": [ { "source": "users", "destination": "/home", "type": "bind" }, { "source": "none", "destination": "/home/wking", "type": "tmpfs" } ] Where the source 'users' directory already contained a 'wking' subdirectory. So by the time the tmpfs was setup, the destination directory would exist, but at validation time (without having run the bind mount) the tmpfs destination directory would not exist. The second (destination is a directory) errors on valid cases like: "mounts": [ { "source": "/etc/resolv.conf", "destination": "/etc/resolv.conf", "type": "bind" } ] because binding files to files works. In a shell: # touch test # mount --bind /etc/resolv.conf test # umount test However binding directories to files does not work: # mount --bind /etc test mount: mount point /tmp/test is not a directory Figuring out which mount configurations are valid and which aren't may be possible, but I'm pretty sure it's more trouble than we want to get into. There may be room for other mount tests (e.g. comparing 'type' against /proc/filesystems as a host-specific test), but I'm leaving those to subsequent pull requests. Signed-off-by: W. Trevor King <wking@tremily.us>
This was referenced May 20, 2016
mrunalp
pushed a commit
that referenced
this pull request
May 23, 2016
These landed as CheckMounts in 647e355 (bundle validate update to 0.3.0, 2016-02-23, #20), but both checks are too strict. The first (destination exists in the rootfs) errors on valid cases like: "mounts": [ { "source": "users", "destination": "/home", "type": "bind" }, { "source": "none", "destination": "/home/wking", "type": "tmpfs" } ] Where the source 'users' directory already contained a 'wking' subdirectory. So by the time the tmpfs was setup, the destination directory would exist, but at validation time (without having run the bind mount) the tmpfs destination directory would not exist. The second (destination is a directory) errors on valid cases like: "mounts": [ { "source": "/etc/resolv.conf", "destination": "/etc/resolv.conf", "type": "bind" } ] because binding files to files works. In a shell: # touch test # mount --bind /etc/resolv.conf test # umount test However binding directories to files does not work: # mount --bind /etc test mount: mount point /tmp/test is not a directory Figuring out which mount configurations are valid and which aren't may be possible, but I'm pretty sure it's more trouble than we want to get into. There may be room for other mount tests (e.g. comparing 'type' against /proc/filesystems as a host-specific test), but I'm leaving those to subsequent pull requests. Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: liangchenye liangchenye@huawei.com
Clean the worthless commits in (#4) and re-submit it.