ssh keys for user are not owned by the user [Jaunty] [PATCH]

I see this issue as well.

Why not use os.chown instead of run_cmd in your patch?

At first I tried to go the os.chown way, but there were a few complications that made the code less elegant.

First, the chown command takes, as the 2nd and 3rd arguments, the uid and gid of the user. The user that needs to own the .ssh directory and its contents is a user that is created within the chroot. While it is possible to get the information with the pwd module, it is a lot easier to simply do the chroot and then use chown command within the chroot.

Other suggestions or code are welcome for review. I am not a developer on this project, so it will be up to them on what they accept/commit as a fix.

added a branch link

On Fri, Apr 3, 2009 at 6:27 PM, Todd Deshane <email address hidden> wrote:
> First, the chown command takes, as the 2nd and 3rd arguments, the uid
> and gid of the user. The user that needs to own the .ssh directory and
> its contents is a user that is created within the chroot. While it is
> possible to get the information with the pwd module, it is a lot easier
> to simply do the chroot and then use chown command within the chroot.

vmbuilder shouldn't be creating more than a single user; it's not the
place for any heavy user management. As such, I can't see a situation
where the initial users's uid and gid wouldn't be 1000.

> I can't see a situation where the initial users's uid and gid wouldn't be 1000.

This situation arises when vmbuilder is being used to build standard images which are going to be used by other parties. For example, when vmbuilder is used to build public images for Amazon EC2:

 https://bugs.launchpad.net/ubuntu-on-ec2/+bug/339805

While this was cherry-picked in trunk, the code was modified and is broken in karmic and trunk:
            self.run_in_target('chown', '-R', '%s:%s' % (self.vm.user,)*2, '/home/%s/.ssh/' % (self.vm.user)).

see bug #436835