New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SplitGPG fails if VM containing the key is not running #1283

Closed
qjoo opened this Issue Oct 6, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@qjoo

qjoo commented Oct 6, 2015

Expected behavior: GPG key containing VM is started on demand (R2 behavior)

If the VM is already running everything works fine.

This is on R3.0 with the default F21 template.

Traceback ("manual" copy paste :)

Rpc allowed: mail gpg-key qubes.Gpg
Traceback
 File /usr/lib/qubes/qrexec-policy, line 226
 File /usr/lib/qubes/qrexec-policy, line 221
  do_execute(domain, target, user, service_name, process_ident)
 File /usr/lib/qubes/qrexec-policy, line 123, in do_execute
  spawn_target_if_necessary(target)>
 File /usr/lib/qubes/qrexec-policy, line 109, in spawn_target_if_necessary
  if is_domain_running(target):
 File /usr/lib/qubes/qrexec-policy, line 88, in is_domain_running
    libvirt_dom = vmm.libvirt_conn.lookupByName(target)
 File /usr/lib64/python2.7/site-packages/libvirt.py line 3964 in lookupByName
   if ret is None:raise libvirtError('virDomainLookupByName() failed', conn=self)
libvirt.libvirtError: Domain not found 
@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Oct 6, 2015

Member

I'm experiencing this too.

Member

andrewdavidwong commented Oct 6, 2015

I'm experiencing this too.

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Oct 7, 2015

Member

Actually, I think this is some kind of "first-run" issue, because now my GPG backend VMs are autostarting on-demand.

Member

andrewdavidwong commented Oct 7, 2015

Actually, I think this is some kind of "first-run" issue, because now my GPG backend VMs are autostarting on-demand.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 7, 2015

Member

On Wed, Oct 07, 2015 at 03:13:11AM -0700, Axon wrote:

Actually, I think this is some kind of "first-run" issue, because now my GPG backend VMs are autostarting on-demand.

Yes, looks like it. But still it is a bug.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Member

marmarek commented Oct 7, 2015

On Wed, Oct 07, 2015 at 03:13:11AM -0700, Axon wrote:

Actually, I think this is some kind of "first-run" issue, because now my GPG backend VMs are autostarting on-demand.

Yes, looks like it. But still it is a bug.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek added a commit to marmarek/qubes-core-admin-linux that referenced this issue Oct 11, 2015

qrexec: fix handling autostarting RPC target VM
Do not reimplement manual VM state checking in qrexec-policy.
`qubes.xml` is loaded anyway, so just use QubesVM object to check if
domain is running.

Fixes QubesOS/qubes-issues#1283

(cherry picked from commit 63e74a0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment