-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check CAP_LAST_CAP while setting privileged #138
Check CAP_LAST_CAP while setting privileged #138
Conversation
@mrunalp , PTAL. |
On Thu, Jul 21, 2016 at 09:39:36AM -0700, hmeng-19 wrote:
This is host-specific (e.g. maybe you're using a host with an old |
@wking , I am testing octools on RHEL7 recently.
|
On Thu, Jul 21, 2016 at 09:49:08AM -0700, hmeng-19 wrote:
That's only a problem if you're also trying to run the container on A --host-specific flag says “Don't be generic, I want to $ ocitools --host-specific generate --privileged --tty --output=config.json --uidmappings=0:0:1024 --gidmappings=0:0:1024 |
@wking , sounds good. It would be nice we can take care both cases:
It is easy to picture both use cases. |
On Thu, Jul 21, 2016 at 10:01:54AM -0700, hmeng-19 wrote:
Agreed, that's why I'm suggesting a global option ;). |
@mrunalp , how do you think about this? |
Sounds good to me. |
fa672ae
to
16626ef
Compare
@@ -84,7 +84,7 @@ var bundleValidateCommand = cli.Command{ | |||
return fmt.Errorf("The root path %q is not a directory.", rootfsPath) | |||
} | |||
|
|||
hostCheck := context.Bool("host-specific") | |||
hostCheck := hostSpecific || context.Bool("host-specific") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want both a global and a per-command --host-specific here. We should drop the per-command option.
And I'm not all that familiar with urfave/cli, but do we really need the package-global hostSpecific
? I'd expect you to be able to pull that from the context
, even though it's set via a global variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want both a global and a per-command --host-specific here. We should drop the per-command option.
I am okay with drop the per-command --host-specific option once @mrunalp and you are okay with it.
I keep it for now just in case some important users are using it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I'm not all that familiar with urfave/cli, but do we really need the package-global hostSpecific? I'd expect you to be able to pull that from the context, even though it's set via a global variable.
I use a global var here to avoid multiple func calls to context.GlobalBool
. However, it does not make too much difference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, here's an example of accessing a global option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Thu, Jul 21, 2016 at 12:31:53PM -0700, hmeng-19 wrote:
I keep it for now just in case some important users are using it.
We haven't tagged an ocitools release yet or said anything about
forward compat in it's command-line API, so I think we're free to
change whatever we want. But if we know of any consumers, giving them
a heads up on the change would be good (ideally as part of a
release-tagging process ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Thu, Jul 21, 2016 at 12:33:31PM -0700, hmeng-19 wrote:
I use a global var here to avoid multiple func calls to
context.GlobalBool
.
What's the drawback to multiple GlobalBool calls? I like that more
than a package global, since it keeps the “single, unambiguous,
authoritative” representation of that setting 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, multiple calls to GlobalBool
are fine. Also, can drop per command option in favor of global.
16626ef
to
06cdef1
Compare
Log level (panic, fatal, error, warn, info, or debug) (default: "error"). | ||
|
||
**--host-specific** | ||
Generate host-specific configs or do host-specific validations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section (including the following paragraph) needs to be genericized now that it's covering both generate and validate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment has been addressed.
06cdef1
to
9125c6d
Compare
privileged := false | ||
if context.IsSet("privileged") { | ||
privileged = context.Bool("privileged") | ||
} | ||
g.SetupPrivileged(privileged) | ||
g.SetupPrivileged(privileged, hostSpecific) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this more, I think that we shouldn't pass this as part of the API. We should have a call to enable hostSpecific on the generate object and then use that variable in individual APIs
g := generate.New()
g.EnableHostSpecific()
g.SetupPrivileged()
...
g.SaveToFile()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Thu, Jul 21, 2016 at 04:01:34PM -0700, Mrunal Patel wrote:
privileged := false if context.IsSet("privileged") { privileged = context.Bool("privileged") }
- g.SetupPrivileged(privileged)
- g.SetupPrivileged(privileged, hostSpecific)
Thinking about this more, I think that we shouldn't pass this as
part of the API. We should have a call to enable hostSpecific on the
generate object and then use that variable in individual APIsg := generate.New() g.EnableHostSpecific() g.SetupPrivileged()
This works for me. I think it depends on the setting though; I prefer
seccomp-only to be a Save(ToFile) parameter and not a Generator-wide
setting 1. The threshold is “can we think of a reason why a single
Generator would need different values in different contexts?”, and
that makes me a bit jumpy (my crystal ball isn't always that clear ;).
But in this case a Generator setting seems safe enough.
9125c6d
to
530f103
Compare
@mrunalp , PTAL. |
@mrunalp , |
@@ -21,7 +21,8 @@ var ( | |||
|
|||
// Generator represents a generator for a container spec. | |||
type Generator struct { | |||
spec *rspec.Spec | |||
spec *rspec.Spec | |||
hostSpecific bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why make this private with a setter (and no getter)? Is there a reason to not make it public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I currently did not think of any cases where Generator.hostSpsecific
is queried outside the package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Fri, Jul 22, 2016 at 10:16:03AM -0700, hmeng-19 wrote:
@@ -21,7 +21,8 @@ var (
// Generator represents a generator for a container spec.
type Generator struct {
- spec *rspec.Spec
- spec *rspec.Spec
- hostSpecific bool
I currently did not think of any cases where
Generator.hostSpsecific
is queried outside the package.
“I can't think of any reason you'd care” is different from “we don't
want people touching this directly”. Since a public field doesn't
require getters/setters, I'd rather keep things public unless we have
reasons to make them private.
On Fri, Jul 22, 2016 at 09:45:37AM -0700, hmeng-19 wrote:
I think so, but this should probably be a separate commit, since it's |
**--host-specific** | ||
Generate host-specific configs or do host-specific validations. | ||
|
||
By default, generator addes process capabilities into the config without |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
“addes” → “adds”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accept. Thanks.
@wking , sounds good. I will work on it after the PR is done. |
530f103
to
6435494
Compare
6435494
to
8b6cb85
Compare
LGTM |
08fd3a7
to
751e18b
Compare
@mrunalp , PTAL. |
gp.HostSpecific = true | ||
} | ||
|
||
g := *gp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need this. It seemed to compile and run fine for me with the following change on top of 751e18b:
diff --git a/cmd/ocitools/generate.go b/cmd/ocitools/generate.go
index ab1f6cc..a6423a0 100644
--- a/cmd/ocitools/generate.go
+++ b/cmd/ocitools/generate.go
@@ -96,12 +96,11 @@ var generateCommand = cli.Command{
},
}
-func setupSpec(gp *generate.Generator, context *cli.Context) error {
+func setupSpec(g *generate.Generator, context *cli.Context) error {
if context.GlobalBool("host-specific") {
- gp.HostSpecific = true
+ g.HostSpecific = true
}
- g := *gp
spec := g.Spec()
if len(spec.Version) == 0 {
@@ -374,7 +373,7 @@ func checkNs(nsMaps map[string]string, nsName string) bool {
return true
}
-func setupLinuxNamespaces(g generate.Generator, needsNewUser bool, nsMaps map[string]string) {
+func setupLinuxNamespaces(g *generate.Generator, needsNewUser bool, nsMaps map[string]string) {
for _, nsName := range generate.Namespaces {
if !checkNs(nsMaps, nsName) && !(needsNewUser && nsName == "user") {
continue
On Tue, Jul 26, 2016 at 11:31:38AM -0700, hmeng-19 wrote:
Except for 1 751e18b looks good to me. I'd rather see this v1.0.0-rc1-compatible change based on the |
Signed-off-by: Haiyan Meng <hmeng@redhat.com>
751e18b
to
bf3f0d4
Compare
@wking , thanks for pointing out. Fixed it. PTAL. |
@mrunalp , PTAL. |
LGTM |
The PR checks whether each cap inside
capability.List()
is <=capability.CAP_LAST_CAP
before adding it intofinalCapList
.This avoids add unsupported cap into
finalCapList
. For example,CAP_AUDIT_READ
is added into the kernel since Linux 3.16, and not supported on RHEL7.Signed-off-by: Haiyan Meng hmeng@redhat.com