Open Stack

On Mon, Jul 30, 2012 at 4:50 PM, Bhuvaneswaran A <bhuvan at apache.org> wrote:

> On Mon, Jul 30, 2012 at 6:31 AM, Doug Hellmann
> <doug.hellmann at dreamhost.com> wrote:
>
> > You've already answered several of my questions on the ticket, but I
> still
> > have some "usability" concerns.
> >
> > How does the keyring system support a single person logging in using
> > multiple user accounts? For example, if I have an admin account and a
> > "regular" user, how do I switch between them based on the operations I
> need
> > to perform?
>
> The password is stored in keyring, for a given user. It also support
> multiple users. The password is stored against the user specified in
> command line, --os-username or environment variable OS_USERNAME.
>
> The sample content of the keyring file ~/.openstack-keyring.cfg is as
> follows:
> [openstack]
> bhuvan = dG4wN2FjxxxxxA==
> test = xYwN2FjxxxxxA==
>

OK, that's good to know.


>
> > Is there a way to disable the behavior of having a password saved to a
> > keyring for a particular user, without uninstalling the python-keyring
> > package (and therefore disabling keyring support for all users)?
>
> The simplest alternative is to specify password using other mechanism,
> in command line or environment variable. It's not possible to prevent
> using keyring, if password is not specified in any of these 2
> mechanisms. The purpose of this patch is, to prevent password prompt.
>

We're going to need to include a way in the openstack cli to disable the
use of the keyring. There will be times when users won't want passwords
saved to a keyring, or where the password that is in the keyring is wrong
or shouldn't be used for some reason. It seems like an environment variable
and a command line switch would cover all of the ways to turn the keyring
off, don't you think?


>
> > The wiki mentions the password being saved using
> > keyring.backend.UncryptedFileKeyring. Does that mean the password is
> saved
> > in cleartext? Is the file protected in some way besides filesystem
> > permissions?
>
> As mentioned in wiki page, the password is stored in base64 format.
>

That doesn't seem any more secure than an environment variable set from a
user's login script. What benefit does keyring give us with this
configuration?


>
> > The mention of one backend implies that there are others. Should we give
> > users a way to choose the backend, in case they have a preference?
>
> python-keyring also support several other backends:
>   1.CryptedFileKeyring
>   2. GnomeKeyring
>   3. KDEKWallet
>   4. OSXKeychain
>   5. Win32CryptoKeyring
>   6. ... and more.
>
> The behaviour of these backends vary for each desktop. For instance,
> GnomeKeyring may prompt for keyring password, once per login session.
> CryptedFileKeyring may prompt for keyring password, every time. It's
> as good as not using keyring.
>

On the other hand, different users will be running in different
configurations. Maybe they *do* have a desktop environment, and want to use
one of those "real" keyring managers, instead of the simple INI file
described above. Does the keyring library have some way to detect which
backends are available at runtime? Or does the application (or user) have
to specify one explicitly?


>
> > How does the use of the keyring affect scripting using the command line
> > tool? Can a script access the keyring, or does it need to use the other
> > options?
>
> Yes. The script could be managed with any python script, using the
> same methods exposed in "keyring" python module.
>   -- get_password() -- to get the password for given user.
>   -- set_password() -- to set the password in keyring.
>

I was not clear. I meant could a shell script running the new cli access
the keyring. It sounds like that is not an issue, based on what you say
below.


>
> > In one review comment you mention a few desktop apps that know how to
> > manipulate the keyring to manage its contents. What about remote access
> via
> > ssh, where a desktop environment is not available? Does the keyring
> library
> > include tools for manipulating the file, or do we need to build our own?
> If
> > so, what tools would be needed?
>
> This was applicable for older patch, wherein we rely on
> desktop/environment specific backend. With older patch, if GNOME
> desktop is used, GnomeKeyring backend is used; if no desktop is used,
> CryptedFileKeyring backend is used. With new patch, irrespective of
> whether desktop is enabled, UncryptedFileKeyring backend is used. With
> this patch, the keyring behaviour is uniform across all systems in
> which we deploy openstack.
>

That resolves my concern, but does not seem to give us any useful features.
We could achieve the same effect using just the environment variable. It
seems like we want to use the "best" keyring method available, if we're
going to use one at all.


>
> In summary, the primary goal of this patch is to reuse the password
> entered in the prompt once, and prevent the user from entering the
> password again. Ultimately, the password is not exposed in environment
> or command line (ps). It also facilitate the automated script wherein
> the "openstack" client might be used. In such case, the password is
> not read from prompt, but from keyring.
> --
> Regards,
> Bhuvaneswaran A
> www.livecipher.com
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120730/997d5ece/attachment.html>