lava-deployment-tool smashes ownership on the entire user homedir

Bug #1197567 reported by Paul Sokolovsky
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LAVA Deployment Tool
Fix Released
Critical
Matthew Hart

Bug Description

http://bazaar.launchpad.net/~linaro-validation/lava-deployment-tool/trunk/revision/238 introduced command

"sudo chown -R $LAVA_SYS_USER:$LAVA_SYS_USER $sshdir/.." (line 456 in diff above). What that command effectively does is overrides ownership of the entire user home dir.

In my case it's:

1) 250G (I first thought it install db or something, then switched to other tasks, then remembered in an hour when it still worked which raised alarm).
2) Contains carefully set ownership to allow daemons/cronjobs run, so lava-deployment-tool broke/compromised my system.

The above issues could happen to any other user of course. It's hard to tell where that line could come from, it appears to be cut&paste from earlier commit by "221.1.8 andy.doan", in another if branch, where it at least was latent. It doesn't make sense there still, so it's likely typo/thinko of "sudo chown $LAVA_SYS_USER $sshdir/.." (note: no -R), i.e. reassurance that path to ~/.ssh/ adheres to sshd constraints (that all/most intermediate components should be owned by the user).

Overall, following points should be observed when making any changes to lava-deployment-tool:

1. lava-deployment-tool can be run on an existing production system, and users trust lava-deployment-tool to behave properly (well, I did trust).
2. Based on the above, lava-deployment-tool should avoid doing a) any irreversible changes; b) any changes not directly related to LAVA installation - at least not without asking user confirmation (or without accepting "--force --force --force" switches).

Please treat as critical.

Changed in lava-deployment-tool:
importance: Undecided → Critical
assignee: nobody → Matthew Hart (matthew-hart)
Revision history for this message
Matthew Hart (matthew-hart) wrote :

Hi Paul

I don't think I quite understand the issue fully, could you please add some details:

Do you mean l-d-t is overwriting permissions of your own personal home directory, or of the "lava-$instance" user that it has created, or a different lava instance user?

Were you deploying a new instance or upgrading an existing one? The change was done on the basis that the home folder which is being chown'd (/srv/lava/instances/$instance/home) has just been created by l-d-t so should be empty, is that not the case?

Thanks.

Revision history for this message
Paul Sokolovsky (pfalcon) wrote :

> Do you mean l-d-t is overwriting permissions of your own personal home directory, or of the "lava-$instance" user that it has created, or a different lava instance user?

It recursively overwrites ownership of files of my own personal home directory, because by default lava-deploy-tool doesn't create any users by uses current user (and that's intended behavior in my case).

> on the basis that the home folder which is being chown'd (/srv/lava/instances/$instance/home) has just been created by l-d-t so should be empty, is that not the case?

No, per above.

Revision history for this message
Paul Sokolovsky (pfalcon) wrote :

> Were you deploying a new instance or upgrading an existing one?

I just run it as "./lava-deployment-tool install -d <instname>" and use defaults for all choices.

Revision history for this message
Matthew Hart (matthew-hart) wrote :

Ok Paul, totally understood.

I had no idea that developer mode caused the LAVA_SYS_USER to be set as the current running user.

It looks like l-d-t only checks for the existence of ~/.ssh/id_rsa before going off on this folder creation and chown rampage, so I'll try to make it behave properly when in developer mode.

Agree it is critical.

Changed in lava-deployment-tool:
status: New → In Progress
Changed in lava-deployment-tool:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.