Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
OS Login implementation is incorrect #2503
Container Linux Version
OS Login to work, but only when it's actually enabled for the VM/project.
First off, OS Login should only be allowed when it is enabled for the project and/or VM. See here for reference. As far as I can see this is not checked anywhere, it will attempt to enable OS Login unconditionally.
Second, the mechanism to enable it on first boot does not work. On a freshly booted CL Alpha GCE VM I see:
It is a symlink though:
Fixed via coreos/coreos-overlay#3414 which should be in the next alpha. You'll need to re-provision to pick up the changes (since the OEM partition does not get updates and this is only running on first boot). Thanks for the report!
We don't do any checking because if it's disabled on the cloud side the bits we enabled will be a no-op, which is fine. Enabling it on the VM should not break the non-oslogin paths (if it does, that's a bug, please let us know!). Is there some other concern you have with blanket enabling it by default?
After talking with the GCE folks they are supportive of configuring it at first boot, since it being either enabled or disabled at boot fits well with the "immutable OS" concept. We didn't design it to meant to be toggled on and off after provisioning for CL. We defaulted to "on" so when oslogin is enabled on the cloud console side, it works with existing vms.
Thanks for the speedy fix!
As far as the activation goes: I see the reasoning behind it and it makes sense. That being said I could imagine a scenario where it is enabled on the project level, but you might want to opt out a few specific VMs for whatever reason, so you'd have
if [ "$(curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/metadata/enable-oslogin)" == "FALSE" ]; then echo "OS Login is disabled for this VM, not enabling it." exit 0 fi
to the top of the enabler script.
Hrmm. My main concern with that is if someone wanted to turn on oslogin later, they can't without manual intervention. If you opt out for a vm then it's still deactivated, even though the bits are included and activated in the OS; gce will fail login attempts if oslogin is off. When someone tries to log in as if they were using oslogin the os will try the nss/pam modules but gce will hand back responses causing it to fail and prevent the login.
I think I want to keep it as is since having it on doesn't do any harm and users might want to activate it later without reprovisioning (assuming they have a CL provisioned with a initial version new enough).
As a side note, you could add that check as a (really ugly)
Perhaps we can have coreos-metadata expose
Either way sounds reasonable to me. To be perfectly honest I don't have a horse in this race as we're not disabling OS Login on a per-VM basis, I just figured it might be worth mentioning that it's a valid use-case. I hadn't considered that the authentication server on Google's side would reject the login attempt if it's turned off, so in the end it probably really doesn't make a difference if it's turned on unconditionally on the OS side.