Skip to content
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

Add Windows configs support #33169

Merged
merged 1 commit into from May 16, 2017

Conversation

@johnstep
Copy link
Member

commented May 11, 2017

Signed-off-by: John Stephens johnstep@docker.com

This change implements configs support for Windows by writing all configs to a single container directory, mounted at C:\ProgramData\Docker\internal\configs, and creating symlinks from the target to these files.

)

const (
containerInternalConfigsDirPath = `C:\ProgramData\Docker\internal\configs`

This comment has been minimized.

Copy link
@AkihiroSuda

AkihiroSuda May 12, 2017

Member

ALLUSERSPROFILE?

This comment has been minimized.

Copy link
@jhowardmsft

jhowardmsft May 12, 2017

Contributor

We made a mistake choosing programdata over program files in the daemon due to the ACLing. I think this should be under program files so we don't have to fix later, and have the right ACLs when running a container as a regular non-admin user.

This comment has been minimized.

Copy link
@johnstep

johnstep May 13, 2017

Author Member

I don't think Program Files is the right place for this. We can adjust the security descriptor, if necessary, though file security comes from the host, and the volume is mounted read-only. My primary concern with ProgramData\Docker is overlap with the service configuration directory if we allow nested containers. This is not really an issue, so long as subdirectory names are managed carefully, but could be confusing. Any other suggestions?

This comment has been minimized.

Copy link
@AkihiroSuda

AkihiroSuda May 15, 2017

Member

My intention of my comnent was os.Getenv would be preferred over hardcoding 😅

ProgramData itself looks good

This comment has been minimized.

Copy link
@johnstep

johnstep May 15, 2017

Author Member

In the current Windows container implementation, the container system drive is always C, and we cannot easily read the container environment from the host.

@thaJeztah

This comment has been minimized.

Copy link
Member

commented May 12, 2017

ping @jhowardmsft PTAL 😅

// In s.Mounts
mounts, err := daemon.setupMounts(c)
if err != nil {
return nil, err
}

if len(c.ConfigReferences) > 0 {
if err := daemon.Mount(c); err != nil {

This comment has been minimized.

Copy link
@jhowardmsft

jhowardmsft May 12, 2017

Contributor

This is another case of a relatively expensive mount/unmounts which should be avoided if possible.

This comment has been minimized.

Copy link
@johnstep

johnstep May 12, 2017

Author Member

The container file system is mounted for creating the symlinks. I believe it is already mounted, at this point, with process isolation, so this should just be reference counting. It is not mounted earlier for Hyper-V, so this is required.

This comment has been minimized.

Copy link
@jhowardmsft

jhowardmsft May 12, 2017

Contributor

Right, but a much shorter code-path would be to move the isHyperV calculation a few lines below this change up, and key off that. IOW. It'll also make the check much more obvious than indirectly relying on ref counting.

if isHyperV {
    if err  := daemon.Mount(c)....
}

This comment has been minimized.

Copy link
@jhowardmsft

jhowardmsft May 12, 2017

Contributor

Per slack, but putting on GH too. createSpec on Windows is called for starting a container. For Hyper-V containers, it's not safe to mount the sandbox on the host if the container has been started before as it's an attack vector on the host.

This comment has been minimized.

Copy link
@johnstep

johnstep May 12, 2017

Author Member

Yes, good catch. I will ensure this is only done if the container has never been started. I will also update the corresponding code in #32208.

@johnstep johnstep force-pushed the johnstep:windows-configs branch 2 times, most recently from 5532bfa to 7d9be43 May 12, 2017

@thaJeztah

This comment has been minimized.

Copy link
Member

commented May 15, 2017

@jhowardmsft PR was updated PTAL

@johnstep

This comment has been minimized.

Copy link
Member Author

commented May 16, 2017

This will be rebased, with some manual editing, once #32208 is merged.

@johnstep johnstep force-pushed the johnstep:windows-configs branch from 7d9be43 to 386a3b7 May 16, 2017

@johnstep

This comment has been minimized.

Copy link
Member Author

commented May 16, 2017

Updated and test locally, with and without secrets in the same service.

John Stephens
Add Windows configs support
Signed-off-by: John Stephens <johnstep@docker.com>

@johnstep johnstep force-pushed the johnstep:windows-configs branch from 386a3b7 to e0d533b May 16, 2017

// The container file system is mounted before this function is called,
// except for Hyper-V containers, so mount it here in that case.
if isHyperV {
if err := daemon.Mount(c); err != nil {
return nil, err
}
defer daemon.Unmount(c)

This comment has been minimized.

Copy link
@jhowardmsft

jhowardmsft May 16, 2017

Contributor

👍

@jhowardmsft

This comment has been minimized.

Copy link
Contributor

commented May 16, 2017

LGTM. Close enough to the secrets PR in terms of change, so most of my previous nits are addressed.

if err := ioutil.WriteFile(fPath, config.Spec.Data, configRef.File.Mode); err != nil {
return errors.Wrap(err, "error injecting config")
}
}

This comment has been minimized.

Copy link
@aaronlehmann

aaronlehmann May 16, 2017

Contributor

As a followup, I wonder if this code could be shared with the Linux implementation. It looks very similar.

This comment has been minimized.

Copy link
@johnstep

johnstep May 16, 2017

Author Member

Yes, I think this is worth looking into. The Windows version is essentially a subset, since we do not yet have an equivalent to UID, GID, and mode. It is also similar to setupSecretDir.

@aaronlehmann

This comment has been minimized.

Copy link
Contributor

commented May 16, 2017

LGTM

@johnstep johnstep merged commit 7658851 into moby:master May 16, 2017

6 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 34211 has succeeded
Details
janky Jenkins build Docker-PRs 42811 has succeeded
Details
powerpc Jenkins build Docker-PRs-powerpc 3196 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 14047 has succeeded
Details
z Jenkins build Docker-PRs-s390x 2915 has succeeded
Details

@johnstep johnstep deleted the johnstep:windows-configs branch May 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.