Bug 1260801

Summary:	virt-builder --ssh-inject doesn't set proper permissions on created files
Product:	Red Hat Enterprise Linux 7	Reporter:	Richard W.M. Jones <rjones>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	leiwang, linl, ptoscano, rbalakri, rsawhill, sherold, wshi, xchen
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libguestfs-1.32.0-2.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1260778	Environment:
Last Closed:	2016-11-03 17:54:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1218766, 1260778
Bug Blocks:	1288337, 1301891

Description Richard W.M. Jones 2015-09-07 21:21:32 UTC

NOTE: Do NOT affect RHEL 7.2.  Cloning the bug just so we
check that the patch is included in RHEL 7.3 (assuming we
do the rebase).

+++ This bug was initially created as a clone of Bug #1260778 +++

Description of problem:

  When using virt-builder --ssh-inject, the permissions of ~/.ssh and ~/.ssh/authorized_keys are not set appropriately.

Version-Release number of selected component (if applicable):

  Checked in latest available Fedora non-testing version
  (libguestfs-tools-c-1.30.0-1.fc22.x86_64)

How reproducible:

  Hmmm. 100% it seems.

Steps to Reproduce:

  1. virt-builder <TEMPLATE> --ssh-inject root
  2. Import image with virt-install or use guestfish/guestmount to pull up rootfs
  3. Execute: ls -la /root/.ssh

Actual results:

  total 4
  drwxr-xr-x. 2 root root  28 Sep  7 13:04 .
  dr-xr-x---. 3 root root  97 Sep  7 13:04 ..
  -rw-r--r--. 1 root root 397 Sep  7 13:04 authorized_keys
  
Expected results:

  total 4
  drwx------. 2 root root  28 Sep  7 13:04 .
  dr-xr-x---. 3 root root  97 Sep  7 13:04 ..
  -rw-------. 1 root root 397 Sep  7 13:04 authorized_keys

--- Additional comment from Ryan Sawhill on 2015-09-07 14:05:47 EDT ---

When the ssh-copy-id command creates ~/.ssh and ~/.ssh/authorized_keys it sets the perms to 0700 and 0600, respectively.

That said, in my email correspondence, I was wrong to suggest that --ssh-inject was failing for me because of this. Turns out it was a quirk of my current setup with ssh-agent and too many keys.

I still think it would be a good idea to set the same perms that ssh-copy-id does, but not that big of a deal I guess.

--- Additional comment from Richard W.M. Jones on 2015-09-07 16:43:13 EDT ---

I looked at ssh-copy-id and ssh and both are creating ~/.ssh with
mode 0700, so that looks like the right thing to do.

--- Additional comment from Richard W.M. Jones on 2015-09-07 17:17:21 EDT ---

Patch posted:
https://www.redhat.com/archives/libguestfs/2015-September/msg00021.html

Comment 1 Pino Toscano 2015-10-16 08:58:57 UTC

This has been fixed with
https://github.com/libguestfs/libguestfs/commit/5ed4388ecd5fdb7639622ee4fba317c276547257
which is in libguestfs >= 1.31.5.

The rebase (bug #1218766) will pick this bug fix (and the feature too, actually :) ) as well.

Comment 3 Xianghua Chen 2016-06-28 02:49:14 UTC

Verified with the packages:
libguestfs-1.32.5-6.el7.x86_64

Verify steps:
1. Build a Fedora guest image and inject your public key and a string to the guest:
# virt-builder fedora-23 --arch i686 -o fedora-23.img --ssh-inject root:file:/root/.ssh/id_rsa.pub --ssh-inject  root:string:"ssh-rsa AAtesttesttest"

Command finished successfully and there should be a image: fedora-23.img2. 

2. Check the permission:
# guestfish -a tmp.qcow2 -i ll /root/.ssh/  
drwx------  2 root root   28 Jun 21 09:14 .  
dr-xr-x---. 5 root root 4096 Jun 21 09:14 ..  
-rw-------  1 root root  402 Jun 21 09:14 authorized_keys

The permission of .ssh is 0700 and authorized_keys is 0600.

So verified.

Comment 5 errata-xmlrpc 2016-11-03 17:54:43 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2576.html