Code review comment for lp:~dooferlad/offspring/linaro_offspring_add_bzr_ssh

On Thu, 2011-10-06 at 17:31 +0000, James Tunnicliffe wrote:
> On 6 October 2011 17:08, Guilherme Salgado <email address hidden> wrote:
> >> The last comment James W made about home directories was that they may
> >> be shared between builders, so we don't want to transport the
> >> launchpad user using ~/.bazaar/authentication.conf to the build script
> >> because it could change before it is used.
> >
> > My understanding is that they are only shared between builds on a
> > certain builder, which is not a problem as they're serialized and we're
> > killing ssh-agent between builds.
>
> I guess I am worried that a builder could be a multi-core machine and
> all instances of a user could share 1 home directory on that machine.
> Basically, the current solution is always safe, no matter what the
> disk situation is and using lp-login is with the current set up, but
> may not be in the future. I would just rather go with something that
> is more robust.

Fair enough

>
> > The problem is that there are no per-project permissions in Offspring;
> > if a user can change one project they can change all of them (modulo the
> > private ones, after our work is complete).
> >
> > If we keep it only in the admin UI we'd have to give the ssh keys to
> > someone with admin rights, and this someone would then be given the ssh
> > keys of all landing teams.
> >
> > Or maybe we could have one member of each LT as an admin in Offspring so
> > that they can do it themselves. With your changes to not show the
> > existing ssh key that means they'd only be able to enter new ssh keys
> > for projects but not see existing ones. I don't think it is a good idea
> > to have one person from each LT with admin rights though.
>
> How about:
> * When creating a project, you can enter an SSH key and user
> * Once a project is created...
> - If it is private, you can change the SSH key (current interface)
> - If it is public, you can't change the SSH key
> * The admin interface always allows you to change the SSH key

Sounds good to me, and maybe we can even allow editing ssh keys of
public projects... Changing the ssh key of an existing project won't
give an attacker access to anything they don't already have access to
anyway.

>
> Another option would be disabling SSH users + keys for all public
> projects and leave them as they are for private ones once both our
> patches are working together.
>
> The only other option In can think of is recording the user that
> created the project and, if it is public, only letting that user
> change the SSH user and key. For private projects we could give the
> project group permission.
>
> What do you think?
>

--
Guilherme Salgado <https://launchpad.net/~salgado>