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.

Sign up for GitHub

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

Jump to bottom

chmod of keys can occur before group is created. #362

Closed
kevincox opened this issue Nov 23, 2015 · 8 comments
Closed

chmod of keys can occur before group is created. #362

kevincox opened this issue Nov 23, 2015 · 8 comments
Labels
bug

Comments

@kevincox
Copy link
Contributor

Occasionally when provisioning a new node I get the following error:

s10> uploading key ‘ssl_www.kevincox.ca.crt’...
s10> chown: invalid group: ‘root:ssl_www.kevincox.ca’

This can be worked around by:

  1. Commenting out the key.
  2. Deploying (creating the group).
  3. Uncommenting the key.
  4. Deploying.
@basvandijk
Copy link
Member

The problem is that in activate_configs(...) the keys are send m.send_keys() before activating the new configuration m.switch_to_configuration(...) and creating the needed users and groups. I guess this ordering makes sense because certain services may not function correctly if the needed keys are not present.

The solution is probably to take the user and group configuration from the new configuration and only activate that part, then send the keys and finally activate the full new configuration.

basvandijk added a commit to basvandijk/nixops that referenced this issue Dec 1, 2015
@basvandijk
Set the owner of a key using an id instead of a name
a6d9690 
This is a WIP patch and is not working yet. This is an attemt to fix NixOS#362.

This allows deploying the keys without adding the user accounts first.

I get the following error:

  myMachine......................> uploading key ‘test’...
  myMachine......................> error: 'uid'
@basvandijk
Copy link
Member

Another idea I have is to set the key owner using the UID and GID instead of the user name and group name which doesn't require the user and group accounts to be installed.


~~~I'm probably doing something wrong with how I use my [setIds](https://github.com/basvandijk/nixops/blob/a6d9690705c30fdffebdcf562248cc1770294c5d/nix/keys.nix#L70) function.~~~

~~~Does somebody know why the `uid` property is not ending up in the XML file?~~~

UPDATE: this is now working.

basvandijk added a commit to basvandijk/nixops that referenced this issue Dec 5, 2015
@basvandijk
Fix NixOS#362: chown the key using the uid and gid
161296c 
Previously the owner of the uploaded key would be set to the specified
user name and group name. However, when the configuration which defines
this user and group is not yet activated the chown operation will fail.

What we now do instead is set the owner of the key using the UID and GID
computed from the configuration.

This does enable a small attack window after the chown UID:GID and
before the activation of the new configuration which adds the new user
and group. If there's an existing user or group with the specified UID
or GID respectively he might be able to read the key during that window.
basvandijk added a commit to basvandijk/nixops that referenced this issue Dec 5, 2015
@basvandijk
Fix NixOS#362: chown the key using the uid and gid
4555dcf 
Previously the owner of the uploaded key would be set to the specified
user name and group name. However, when the configuration which defines
this user and group is not yet activated the chown operation will fail.

What we now do instead is set the owner of the key using the UID and GID
computed from the configuration.

This does enable a small attack window after the chown UID:GID and
before the activation of the new configuration which adds the new user
and group. If there's an existing user or group with the specified UID
or GID respectively he might be able to read the key during that window.
@basvandijk
Copy link
Member

I've created a pull request which fixes this.

@aszlig aszlig added the bug label Dec 8, 2015
@aszlig aszlig mentioned this issue Dec 8, 2015
Closed
@basvandijk basvandijk mentioned this issue Dec 8, 2015
Closed
@basvandijk
Copy link
Member

@aszlig had the following idea in #369 to fix this issue:

... a better idea probably would be to use (bind) mount units directly on each key (or maybe on /run/keys in the short run), so services depending on a particular key will block until it is available. That at least would prevent races and the need to explicitly depend on keys.target.

@ryanartecona
Copy link
Contributor

I also just ran into this issue. Looking forward to a fix!

@kevincox
Copy link
Contributor Author

Yeah, this is a massive pain when setting up new servers or services as instead of a single-step process I now have to edit my config to not set the group, deploy then revert the config and deploy a second time.

ryanartecona added a commit to ryanartecona/nixops that referenced this issue Feb 25, 2016
@ryanartecona
Delay chown of keys until user/group both exist
c383e9b 
Instead of chowning keys to their user/group every time they are sent,
only attempt the chown during send-keys if the user and group both
exist, and again do a chown during activation after the users and groups
have been created.

One result is that if a key and its user and/or group are to be created
in the same `nixops deploy`, the key will first be uploaded and owned
by root:root, then chmod'd, then late in activation the key will be
chowned to the newly created user/group. This includes a node's first
deploy, when it has neither keys nor users/groups.

Another result is that between send-keys and the next deploy (often,
but not necessarily, in the same `nixops deploy`), a key may
have its permissions set as configured, but _not_ be owned by the
configured user/group (instead root:root), which is presumed safe.

fixes NixOS#362, fixes NixOS#232
ryanartecona added a commit to ryanartecona/nixops that referenced this issue Feb 26, 2016
@ryanartecona
Delay chown of keys until user/group both exist
4f0df04 
Instead of chowning keys to their user/group every time they are sent,
only attempt the chown during send-keys if the user and group both
exist, and again do a chown during activation after the users and groups
have been created.

One result is that if a key and its user and/or group are to be created
in the same `nixops deploy`, the key will first be uploaded and owned
by root:root, then chmod'd, then late in activation the key will be
chowned to the newly created user/group. This includes a node's first
deploy, when it has neither keys nor users/groups.

Another result is that between send-keys and the next deploy (often,
but not necessarily, in the same `nixops deploy`), a key may
have its permissions set as configured, but _not_ be owned by the
configured user/group (instead root:root), which is presumed safe.

fixes NixOS#362, fixes NixOS#232
@ip1981
Copy link
Contributor

ip1981 commented May 22, 2016

I use IDs instead of names

user = toString allusers.${name}.uid;

@basvandijk basvandijk mentioned this issue Jun 7, 2016
Closed
@domenkozar
Copy link
Member

See #400

ryanartecona added a commit to ryanartecona/nixops that referenced this issue Jun 24, 2016
@ryanartecona
Delay chown of keys until user/group both exist
cca4eb5 
Instead of chowning keys to their user/group every time they are sent,
only attempt the chown during send-keys if the user and group both
exist, and again do a chown during activation after the users and groups
have been created.

One result is that if a key and its user and/or group are to be created
in the same `nixops deploy`, the key will first be uploaded and owned
by root:root, then chmod'd, then late in activation the key will be
chowned to the newly created user/group. This includes a node's first
deploy, when it has neither keys nor users/groups.

Another result is that between send-keys and the next deploy (often,
but not necessarily, in the same `nixops deploy`), a key may
have its permissions set as configured, but _not_ be owned by the
configured user/group (instead root:root), which is presumed safe.

fixes NixOS#362, fixes NixOS#232
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@domenkozar @ip1981 @aszlig @kevincox @basvandijk @ryanartecona