* Sessions support for read:self and cancel:self permissions. This is automatic with fallback; no API change is needed.
* Strips out values from listing if only self actions are allowed on the resource and the user ID is different. This prevents a default ACL of id=*;type=session;actions=read:self,cancel:self from causing all values to be visible when listing.
* Adds an unprivileged user to development/testing instances. This user has only default permissions plus the ability to authorize sessions in the default target.
Create Schema Manager and propagate contexts into the DB calls downstream.
Add checks at controller startup and database init for correct schema version and schema migration dirty bit being set.
This also then removes support for docker-based containing starting (for
now) from platforms other than windows/darwin/linux as there are build
issues on several.
I don't think the conditions exist here that necessitated it being
introduced into Vault, but I do sometimes see a baffling condition where
the address coming from the flag is empty. I don't think we need this so
take it out.
This also shifts some logic around to better prepare for non-dev-mode
workloads, although it does not actually call the KMS creation functions
and initial auth method creation from non-dev commands yet.
This is useful if you, for instance, want Terraform to be 100%
responsible for creation of resources (outside of the static ones that
cannot be removed or modified, like u_anon). This will mean using the
recovery mechanism for initial setup, but that isn't an issue once TF
supports that :-)
This is only compiled in when a `dev` build tag is specified (see #75)
for safety. Attempting to use the flag without that tag at build time
will fail. However, it is always available within the codebase itself so
that tests can be written against this functionality in a programmatic
way.
Manual testing was performed; no plans to add automated ones as this
isn't production-necessary nor exported functionality.
This can be used in tests to get access to a controller that behaves
just like a dev controller but doesn't require the normal Command bits
(UI, etc).
This can be enhanced over time as needed; for now it's pretty simple but
it's good enough to be used for API tests. A simple project create/read
API test is added as well, which serves to show the programmatic model
(as well as test those functions at the API level).
These changes create a dev org in the database on startup.
They also plumb through a dev-org-id flag that allows specifying a chosen org ID in dev mode.
The logic will allow us to let people specify a default org ID in the config file too, although currently that's not enabled.
Several other improvements were made as well:
* Consolidation of some code from across the server commands
* Plumbing shutdownch through so we can use it for canceling contexts during startup
Since client code uses the package name as a prefix when referring to
the package contents, the names for those contents need not repeat the
package name.
- Rename base.BaseCommand to base.Command
- Rename base.BaseServer to base.Server
- Rename config.DevConfig() to config.Dev()
- Rename config.LoadConfigFile() to config.LoadFile()
- Rename config.NewConfig() to config.New()
- Rename config.ParseConfig() to config.Parse()
- Rename controller.ControllerCommand to controller.Command
- Rename controller.NewController() to controller.New()
- Rename dev.DevCommand to dev.Command
- Rename listener.ListenerFactory to listener.Factory
- Rename listener.NewListener() to listener.New()
- Rename version.GetVersion() to version.Get()
- Rename version.VersionInfo to version.Info
See:
- https://golang.org/doc/effective_go.html#package-names
- https://blog.golang.org/package-names#TOC_3.
- https://github.com/golang/go/wiki/CodeReviewComments#package-names
Jeff Mitchell
Todd Knight
Michael GaffneyandJeff Mitchell
Christian Frichot
Jim