I share Doug's concerns but would state some more strongly. IMO, it is
simply unacceptable to modify user-visible behavior based on whether
some package that happens to be used in an implementation is installed
or not. This package is installed on Ubuntu by default and may be used
by other applications that have nothing to do with OpenStack at all.
The proposed behavior is biased towards a very simple use case of a
single user with a password manually invoking commands at the shell. It
is really up to the administrator of a machine with the client installed
what the security policy should be. As Doug suggested, this change is a
very small piece of an overall security architecture which is not well
spelled out here.
If we really want to go down this road there should be an environment
variable that can be set to turn off this behavior for applications that
do not want it.
-David
On 7/30/2012 9:31 AM, Doug Hellmann wrote:
On Sun, Jul 29, 2012 at 1:37 AM, Bhuvaneswaran A <bhu...@apache.org
<mailto:bhu...@apache.org>> wrote:
Team,
As per patch https://review.openstack.org/#/c/9497/ we are adding
keyring support for "openstack" client. If password is not specified
in command line or environment variable, the user is prompted to enter
password. During this time, the password is stored in keyring. During
next time, the password is read from keyring, instead of prompt. It is
true, if password is not specified in command line or environment
variable.
This behavior is documented in this wiki page:
http://wiki.openstack.org/KeyringSupport
If you have any comments, please let us know.
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?
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 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?
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?
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?
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?
Doug
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp