| Message ID | 1490621195-2228-10-git-send-email-armbru@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 27.03.2017 15:26, Markus Armbruster wrote: > This reverts a part of commit 8a47e8e. We're having second thoughts > on the QAPI schema (and thus the external interface), and haven't > reached consensus, yet. Issues include: > > * BlockdevOptionsRbd member @password-secret isn't actually a > password, it's a key generated by Ceph. > > * We're not sure where member @password-secret belongs (see the > previous commit). > > * How @password-secret interacts with settings from a configuration > file specified with @conf is undocumented. I suspect it's untested, > too. > > Let's avoid painting ourselves into a corner now, and revert the > feature for 2.9. > > Note that users can still configure an authentication key with a > configuration file. They probably do that anyway if they use Ceph > outside QEMU as well. > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > --- > qapi/block-core.json | 3 --- > 1 file changed, 3 deletions(-) Reviewed-by: Max Reitz <mreitz@redhat.com>
On 03/27/2017 08:26 AM, Markus Armbruster wrote: > This reverts a part of commit 8a47e8e. We're having second thoughts > on the QAPI schema (and thus the external interface), and haven't > reached consensus, yet. Issues include: > > * BlockdevOptionsRbd member @password-secret isn't actually a > password, it's a key generated by Ceph. > > * We're not sure where member @password-secret belongs (see the > previous commit). > > * How @password-secret interacts with settings from a configuration > file specified with @conf is undocumented. I suspect it's untested, > too. > > Let's avoid painting ourselves into a corner now, and revert the > feature for 2.9. > > Note that users can still configure an authentication key with a > configuration file. They probably do that anyway if they use Ceph > outside QEMU as well. > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > --- > qapi/block-core.json | 3 --- > 1 file changed, 3 deletions(-) Reviewed-by: Eric Blake <eblake@redhat.com> This time, it's fairly obvious that you aren't affecting -drive usage. > > diff --git a/qapi/block-core.json b/qapi/block-core.json > index 6a7ca0b..2e60ab5 100644 > --- a/qapi/block-core.json > +++ b/qapi/block-core.json > @@ -2618,9 +2618,6 @@ > # @server: Monitor host address and port. This maps > # to the "mon_host" Ceph option. > # > -# @password-secret: The ID of a QCryptoSecret object providing > -# the password for the login. > -# > # Since: 2.9 > ## > { 'struct': 'BlockdevOptionsRbd', >
On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: > This reverts a part of commit 8a47e8e. We're having second thoughts > on the QAPI schema (and thus the external interface), and haven't > reached consensus, yet. Issues include: > > * BlockdevOptionsRbd member @password-secret isn't actually a > password, it's a key generated by Ceph. > > * We're not sure where member @password-secret belongs (see the > previous commit). > > * How @password-secret interacts with settings from a configuration > file specified with @conf is undocumented. I suspect it's untested, > too. It's tested, at least to some extent -- it works on my setup; it will override whatever is set in the conf or the keyring. I can alternate between /etc/ceph/keyring, or password-secret, or override the user present in /etc/cep/keyring with a different key via password-secret. So I'd suggest dropping that blurb from the commit message. I agree with the overall reasoning though behind remove all parameters not needed for now, so: Reviewed-by: Jeff Cody <jcody@redhat.com> > > Let's avoid painting ourselves into a corner now, and revert the > feature for 2.9. > > Note that users can still configure an authentication key with a > configuration file. They probably do that anyway if they use Ceph > outside QEMU as well. > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > --- > qapi/block-core.json | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/qapi/block-core.json b/qapi/block-core.json > index 6a7ca0b..2e60ab5 100644 > --- a/qapi/block-core.json > +++ b/qapi/block-core.json > @@ -2618,9 +2618,6 @@ > # @server: Monitor host address and port. This maps > # to the "mon_host" Ceph option. > # > -# @password-secret: The ID of a QCryptoSecret object providing > -# the password for the login. > -# > # Since: 2.9 > ## > { 'struct': 'BlockdevOptionsRbd', > -- > 2.7.4 >
On Mon, Mar 27, 2017 at 10:32:40PM -0400, Jeff Cody wrote: > On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: > > This reverts a part of commit 8a47e8e. We're having second thoughts > > on the QAPI schema (and thus the external interface), and haven't > > reached consensus, yet. Issues include: > > > > * BlockdevOptionsRbd member @password-secret isn't actually a > > password, it's a key generated by Ceph. > > > > * We're not sure where member @password-secret belongs (see the > > previous commit). > > > > * How @password-secret interacts with settings from a configuration > > file specified with @conf is undocumented. I suspect it's untested, > > too. > > It's tested, at least to some extent -- it works on my setup; it will > override whatever is set in the conf or the keyring. I can alternate > between /etc/ceph/keyring, or password-secret, or override the user present > in /etc/cep/keyring with a different key via password-secret. > > So I'd suggest dropping that blurb from the commit message. > > I agree with the overall reasoning though behind remove all parameters not > needed for now, so: > > Reviewed-by: Jeff Cody <jcody@redhat.com> > Wait, hold up on that R-b :) This only seems to revert the comment in the QAPI. You meant to remove the entry from the BlockdevOptionsRbd struct too, right? > > > > Let's avoid painting ourselves into a corner now, and revert the > > feature for 2.9. > > > > Note that users can still configure an authentication key with a > > configuration file. They probably do that anyway if they use Ceph > > outside QEMU as well. > > > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > > --- > > qapi/block-core.json | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/qapi/block-core.json b/qapi/block-core.json > > index 6a7ca0b..2e60ab5 100644 > > --- a/qapi/block-core.json > > +++ b/qapi/block-core.json > > @@ -2618,9 +2618,6 @@ > > # @server: Monitor host address and port. This maps > > # to the "mon_host" Ceph option. > > # > > -# @password-secret: The ID of a QCryptoSecret object providing > > -# the password for the login. > > -# > > # Since: 2.9 > > ## > > { 'struct': 'BlockdevOptionsRbd', > > -- > > 2.7.4 > >
Jeff Cody <jcody@redhat.com> writes: > On Mon, Mar 27, 2017 at 10:32:40PM -0400, Jeff Cody wrote: >> On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: >> > This reverts a part of commit 8a47e8e. We're having second thoughts >> > on the QAPI schema (and thus the external interface), and haven't >> > reached consensus, yet. Issues include: >> > >> > * BlockdevOptionsRbd member @password-secret isn't actually a >> > password, it's a key generated by Ceph. >> > >> > * We're not sure where member @password-secret belongs (see the >> > previous commit). >> > >> > * How @password-secret interacts with settings from a configuration >> > file specified with @conf is undocumented. I suspect it's untested, >> > too. >> >> It's tested, at least to some extent -- it works on my setup; it will >> override whatever is set in the conf or the keyring. I can alternate >> between /etc/ceph/keyring, or password-secret, or override the user present >> in /etc/cep/keyring with a different key via password-secret. >> >> So I'd suggest dropping that blurb from the commit message. Of course. >> I agree with the overall reasoning though behind remove all parameters not >> needed for now, so: >> >> Reviewed-by: Jeff Cody <jcody@redhat.com> >> > > Wait, hold up on that R-b :) > > This only seems to revert the comment in the QAPI. You meant to remove the > entry from the BlockdevOptionsRbd struct too, right? D'oh! Suspect a rebase accident... I'll drop the member and keep your R-by.
On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: > This reverts a part of commit 8a47e8e. We're having second thoughts > on the QAPI schema (and thus the external interface), and haven't > reached consensus, yet. Issues include: > > * BlockdevOptionsRbd member @password-secret isn't actually a > password, it's a key generated by Ceph. > > * We're not sure where member @password-secret belongs (see the > previous commit). > > * How @password-secret interacts with settings from a configuration > file specified with @conf is undocumented. I suspect it's untested, > too. > > Let's avoid painting ourselves into a corner now, and revert the > feature for 2.9. > > Note that users can still configure an authentication key with a > configuration file. They probably do that anyway if they use Ceph > outside QEMU as well. NB, this makes blockdev-add largely useless for RBD from libvirt's POV, since we rely on the password-secret facility working to support apps like openstack which won't configure the global config file for RBD. Not a regression though, since blockdev-add is new - just means we won't be able to use the new feature yet :-( Regards, Daniel
On 03.04.2017 13:37, Daniel P. Berrange wrote: > On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: >> This reverts a part of commit 8a47e8e. We're having second thoughts >> on the QAPI schema (and thus the external interface), and haven't >> reached consensus, yet. Issues include: >> >> * BlockdevOptionsRbd member @password-secret isn't actually a >> password, it's a key generated by Ceph. >> >> * We're not sure where member @password-secret belongs (see the >> previous commit). >> >> * How @password-secret interacts with settings from a configuration >> file specified with @conf is undocumented. I suspect it's untested, >> too. >> >> Let's avoid painting ourselves into a corner now, and revert the >> feature for 2.9. >> >> Note that users can still configure an authentication key with a >> configuration file. They probably do that anyway if they use Ceph >> outside QEMU as well. > > NB, this makes blockdev-add largely useless for RBD from libvirt's POV, > since we rely on the password-secret facility working to support apps > like openstack which won't configure the global config file for RBD. > > Not a regression though, since blockdev-add is new - just means we won't > be able to use the new feature yet :-( How does it make blockdev-add totally useless? The only thing you cannot do is set passwords for rbd. Can this not be added as a new feature in the future? Max
On Mon, Apr 03, 2017 at 02:42:48PM +0200, Max Reitz wrote: > On 03.04.2017 13:37, Daniel P. Berrange wrote: > > On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: > >> This reverts a part of commit 8a47e8e. We're having second thoughts > >> on the QAPI schema (and thus the external interface), and haven't > >> reached consensus, yet. Issues include: > >> > >> * BlockdevOptionsRbd member @password-secret isn't actually a > >> password, it's a key generated by Ceph. > >> > >> * We're not sure where member @password-secret belongs (see the > >> previous commit). > >> > >> * How @password-secret interacts with settings from a configuration > >> file specified with @conf is undocumented. I suspect it's untested, > >> too. > >> > >> Let's avoid painting ourselves into a corner now, and revert the > >> feature for 2.9. > >> > >> Note that users can still configure an authentication key with a > >> configuration file. They probably do that anyway if they use Ceph > >> outside QEMU as well. > > > > NB, this makes blockdev-add largely useless for RBD from libvirt's POV, > > since we rely on the password-secret facility working to support apps > > like openstack which won't configure the global config file for RBD. > > > > Not a regression though, since blockdev-add is new - just means we won't > > be able to use the new feature yet :-( > > How does it make blockdev-add totally useless? The only thing you cannot > do is set passwords for rbd. Can this not be added as a new feature in > the future? Sure, if you want to run an rbd server without any auth its usable, just that isn't something you really want todo from a security pov. Regards, Daniel
On Mon, Apr 03, 2017 at 02:04:42PM +0100, Daniel P. Berrange wrote: > On Mon, Apr 03, 2017 at 02:42:48PM +0200, Max Reitz wrote: > > On 03.04.2017 13:37, Daniel P. Berrange wrote: > > > On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: > > >> This reverts a part of commit 8a47e8e. We're having second thoughts > > >> on the QAPI schema (and thus the external interface), and haven't > > >> reached consensus, yet. Issues include: > > >> > > >> * BlockdevOptionsRbd member @password-secret isn't actually a > > >> password, it's a key generated by Ceph. > > >> > > >> * We're not sure where member @password-secret belongs (see the > > >> previous commit). > > >> > > >> * How @password-secret interacts with settings from a configuration > > >> file specified with @conf is undocumented. I suspect it's untested, > > >> too. > > >> > > >> Let's avoid painting ourselves into a corner now, and revert the > > >> feature for 2.9. > > >> > > >> Note that users can still configure an authentication key with a > > >> configuration file. They probably do that anyway if they use Ceph > > >> outside QEMU as well. > > > > > > NB, this makes blockdev-add largely useless for RBD from libvirt's POV, > > > since we rely on the password-secret facility working to support apps > > > like openstack which won't configure the global config file for RBD. > > > > > > Not a regression though, since blockdev-add is new - just means we won't > > > be able to use the new feature yet :-( > > > > How does it make blockdev-add totally useless? The only thing you cannot > > do is set passwords for rbd. Can this not be added as a new feature in > > the future? > > Sure, if you want to run an rbd server without any auth its usable, just > that isn't something you really want todo from a security pov. > What about using a keyring for rbd?
On 03.04.2017 15:04, Daniel P. Berrange wrote: > On Mon, Apr 03, 2017 at 02:42:48PM +0200, Max Reitz wrote: >> On 03.04.2017 13:37, Daniel P. Berrange wrote: >>> On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: >>>> This reverts a part of commit 8a47e8e. We're having second thoughts >>>> on the QAPI schema (and thus the external interface), and haven't >>>> reached consensus, yet. Issues include: >>>> >>>> * BlockdevOptionsRbd member @password-secret isn't actually a >>>> password, it's a key generated by Ceph. >>>> >>>> * We're not sure where member @password-secret belongs (see the >>>> previous commit). >>>> >>>> * How @password-secret interacts with settings from a configuration >>>> file specified with @conf is undocumented. I suspect it's untested, >>>> too. >>>> >>>> Let's avoid painting ourselves into a corner now, and revert the >>>> feature for 2.9. >>>> >>>> Note that users can still configure an authentication key with a >>>> configuration file. They probably do that anyway if they use Ceph >>>> outside QEMU as well. >>> >>> NB, this makes blockdev-add largely useless for RBD from libvirt's POV, >>> since we rely on the password-secret facility working to support apps >>> like openstack which won't configure the global config file for RBD. >>> >>> Not a regression though, since blockdev-add is new - just means we won't >>> be able to use the new feature yet :-( >> >> How does it make blockdev-add totally useless? The only thing you cannot >> do is set passwords for rbd. Can this not be added as a new feature in >> the future? > > Sure, if you want to run an rbd server without any auth its usable, just > that isn't something you really want todo from a security pov. Indeed, but that's at least an rbd-specific issues. You can still use blockdev-add for other block drivers just fine. ...and I just noticed that I have read your response the wrong way. I didn't notice the "for RBD" and just read "this makes blockdev-add largely useless from libvirt's POV" which sounded wrong. OK, I get it then, sorry. :-) Max
"Daniel P. Berrange" <berrange@redhat.com> writes: > On Mon, Mar 27, 2017 at 03:26:33PM +0200, Markus Armbruster wrote: >> This reverts a part of commit 8a47e8e. We're having second thoughts >> on the QAPI schema (and thus the external interface), and haven't >> reached consensus, yet. Issues include: >> >> * BlockdevOptionsRbd member @password-secret isn't actually a >> password, it's a key generated by Ceph. >> >> * We're not sure where member @password-secret belongs (see the >> previous commit). >> >> * How @password-secret interacts with settings from a configuration >> file specified with @conf is undocumented. I suspect it's untested, >> too. >> >> Let's avoid painting ourselves into a corner now, and revert the >> feature for 2.9. >> >> Note that users can still configure an authentication key with a >> configuration file. They probably do that anyway if they use Ceph >> outside QEMU as well. > > NB, this makes blockdev-add largely useless for RBD from libvirt's POV, > since we rely on the password-secret facility working to support apps > like openstack which won't configure the global config file for RBD. Libvirt could still supply a *local* configuration file. > Not a regression though, since blockdev-add is new - just means we won't > be able to use the new feature yet :-( Unfortunate if true, but QMP interfaces need to be stable, and this one clearly needs more thought.
diff --git a/qapi/block-core.json b/qapi/block-core.json index 6a7ca0b..2e60ab5 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -2618,9 +2618,6 @@ # @server: Monitor host address and port. This maps # to the "mon_host" Ceph option. # -# @password-secret: The ID of a QCryptoSecret object providing -# the password for the login. -# # Since: 2.9 ## { 'struct': 'BlockdevOptionsRbd',
This reverts a part of commit 8a47e8e. We're having second thoughts on the QAPI schema (and thus the external interface), and haven't reached consensus, yet. Issues include: * BlockdevOptionsRbd member @password-secret isn't actually a password, it's a key generated by Ceph. * We're not sure where member @password-secret belongs (see the previous commit). * How @password-secret interacts with settings from a configuration file specified with @conf is undocumented. I suspect it's untested, too. Let's avoid painting ourselves into a corner now, and revert the feature for 2.9. Note that users can still configure an authentication key with a configuration file. They probably do that anyway if they use Ceph outside QEMU as well. Signed-off-by: Markus Armbruster <armbru@redhat.com> --- qapi/block-core.json | 3 --- 1 file changed, 3 deletions(-)