<br><br><div class="gmail_quote">On Mon, Jul 30, 2012 at 4:50 PM, Bhuvaneswaran A <span dir="ltr"><<a href="mailto:bhuvan@apache.org" target="_blank">bhuvan@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Jul 30, 2012 at 6:31 AM, Doug Hellmann<br>
<<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> wrote:<br>
<br>
</div><div class="im">> You've already answered several of my questions on the ticket, but I still<br>
> have some "usability" concerns.<br>
><br>
> How does the keyring system support a single person logging in using<br>
> multiple user accounts? For example, if I have an admin account and a<br>
> "regular" user, how do I switch between them based on the operations I need<br>
> to perform?<br>
<br>
</div><div class="im">The password is stored in keyring, for a given user. It also support<br>
multiple users. The password is stored against the user specified in<br>
command line, --os-username or environment variable OS_USERNAME.<br>
<br>
The sample content of the keyring file ~/.openstack-keyring.cfg is as follows:<br>
[openstack]<br>
bhuvan = dG4wN2FjxxxxxA==<br>
test = xYwN2FjxxxxxA==<br></div></blockquote><div><br></div><div>OK, that's good to know.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
</div><div class="im">> Is there a way to disable the behavior of having a password saved to a<br>
> keyring for a particular user, without uninstalling the python-keyring<br>
> package (and therefore disabling keyring support for all users)?<br>
<br>
</div><div class="im">The simplest alternative is to specify password using other mechanism,<br>
in command line or environment variable. It's not possible to prevent<br>
using keyring, if password is not specified in any of these 2<br>
mechanisms. The purpose of this patch is, to prevent password prompt.<br></div></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
</div><div class="im">> The wiki mentions the password being saved using<br>
> keyring.backend.UncryptedFileKeyring. Does that mean the password is saved<br>
> in cleartext? Is the file protected in some way besides filesystem<br>
> permissions?<br>
<br>
</div>As mentioned in wiki page, the password is stored in base64 format.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
> The mention of one backend implies that there are others. Should we give<br>
> users a way to choose the backend, in case they have a preference?<br>
<br>
</div><div class="im HOEnZb">python-keyring also support several other backends:<br>
1.CryptedFileKeyring<br>
2. GnomeKeyring<br>
3. KDEKWallet<br>
4. OSXKeychain<br>
5. Win32CryptoKeyring<br>
6. ... and more.<br>
<br>
The behaviour of these backends vary for each desktop. For instance,<br>
GnomeKeyring may prompt for keyring password, once per login session.<br>
CryptedFileKeyring may prompt for keyring password, every time. It's<br>
as good as not using keyring.<br></div></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
<br>
</div><div class="im HOEnZb">> How does the use of the keyring affect scripting using the command line<br>
> tool? Can a script access the keyring, or does it need to use the other<br>
> options?<br>
<br>
</div><div class="im HOEnZb">Yes. The script could be managed with any python script, using the<br>
same methods exposed in "keyring" python module.<br>
-- get_password() -- to get the password for given user.<br>
-- set_password() -- to set the password in keyring.<br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
<br>
</div><div class="im HOEnZb">> In one review comment you mention a few desktop apps that know how to<br>
> manipulate the keyring to manage its contents. What about remote access via<br>
> ssh, where a desktop environment is not available? Does the keyring library<br>
> include tools for manipulating the file, or do we need to build our own? If<br>
> so, what tools would be needed?<br>
<br>
</div><div class="im HOEnZb">This was applicable for older patch, wherein we rely on<br>
desktop/environment specific backend. With older patch, if GNOME<br>
desktop is used, GnomeKeyring backend is used; if no desktop is used,<br>
CryptedFileKeyring backend is used. With new patch, irrespective of<br>
whether desktop is enabled, UncryptedFileKeyring backend is used. With<br>
this patch, the keyring behaviour is uniform across all systems in<br>
which we deploy openstack.<br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
<br>
In summary, the primary goal of this patch is to reuse the password<br>
entered in the prompt once, and prevent the user from entering the<br>
password again. Ultimately, the password is not exposed in environment<br>
or command line (ps). It also facilitate the automated script wherein<br>
the "openstack" client might be used. In such case, the password is<br>
not read from prompt, but from keyring.<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Regards,<br>
Bhuvaneswaran A<br>
<a href="http://www.livecipher.com" target="_blank">www.livecipher.com</a><br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>