Permission denied when using Qubes().domains

[Chris Laprise]

Using python3 in dom0, trying to access qubes.Qubes().domains results in
the following error:

/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.136 [...] and kernel driver

It does work when using 'sudo python3' instead.

I don't know if this is considered normal behavior or a bug, as I would
normally expect admin objects to be accessible with normal user privs.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Wojtek Porczyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Feb 20, 2018 at 10:45:55PM -0500, Chris Laprise wrote:
> Using python3 in dom0, trying to access qubes.Qubes().domains results in the
> following error:
>
> /dev/mapper/control: open failed: Permission denied
> Failure to communicate with kernel device-mapper driver.
> Incompatible libdevmapper 1.02.136 [...] and kernel driver
>
> It does work when using 'sudo python3' instead.
>
> I don't know if this is considered normal behavior or a bug, as I would
> normally expect admin objects to be accessible with normal user privs.

Yes, that's expected. qubes.Qubes() is meant to be used from qubesd and if
you'd like to get knowledge about domains, you should use qubesadmin (even as
root). See the qvm-* tools as an example.

- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJajVXhAAoJEL9r2TIQOiNRQ1YQAJP9SdXgDgy9GklIGwlBoe+E
aWbmYddrIAPMmePetXflngkm6pUgHWurTlB+ixdCdabJeDuTRfQAi31AoueKT4+M
OeAwxaE+BvTTV7Pj1dQYwGbDy8YBqJuJWTNBQNDOcmo3LWamAb/dsB6p/QULJsvf
sRHiKW+uB/Do9xh2okWmn2PdDLSoW//AuIMg7xbQDR2/b3i1HtKQj9o+xQIZAF1C
OCmaU6OTbnmx7lmcd8inJp6tfnfjHUtNDDK7bTZAbIjejSjY333GdHkDW1s8BKBL
hREQnDI0cJDE8yUgYGSssZWuPDUcP9X9ZgPLio6a0394fW8hF3HhyIKAYCmyWLLA
iWbVgTsqqlx8/my7jdYXVEnBNOiJB0DRwippAH6ebfsNKw1o4kw/EyIxsu8aq6Kt
2cugO9ZU82XIQzY935JR7QFvo4olTVL/gnRiAnDYc09Zp1KU75QinbK/ueDAWfMO
a8rqauHG23u32EO4pfCytARwBHhNecWPF6uDUBYOfW5/vm2Ty47xUrNDFjjoPQkK
3AwiJLXumeb/O8tiIbEMj6IcRHfRlKnvnzF/zxKrMljHF5bqCtf5+zfQE/YL/gzR
nr7BWw0ma/RzR+SSYKVp653EErRbTeyBwPTnjr6GDbYBYEETjdbyN/9x21t6t9DU
h43SXyH7m1VjpgDGJDPq
=CeKK
-----END PGP SIGNATURE-----

[Chris Laprise]

On 02/21/2018 06:20 AM, Wojtek Porczyk wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Feb 20, 2018 at 10:45:55PM -0500, Chris Laprise wrote:
>> Using python3 in dom0, trying to access qubes.Qubes().domains results in the
>> following error:
>>
>> /dev/mapper/control: open failed: Permission denied
>> Failure to communicate with kernel device-mapper driver.
>> Incompatible libdevmapper 1.02.136 [...] and kernel driver
>>
>> It does work when using 'sudo python3' instead.
>>
>> I don't know if this is considered normal behavior or a bug, as I would
>> normally expect admin objects to be accessible with normal user privs.
>
> Yes, that's expected. qubes.Qubes() is meant to be used from qubesd and if
> you'd like to get knowledge about domains, you should use qubesadmin (even as
> root). See the qvm-* tools as an example.
>

Is there an analog to the R3.2 function vm.run()? Looking at the
difference in R4.0 qvm-run source, that doesn't seem to be the case.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Mar 04, 2018 at 05:46:39AM -0500, Chris Laprise wrote:
> On 02/21/2018 06:20 AM, Wojtek Porczyk wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Tue, Feb 20, 2018 at 10:45:55PM -0500, Chris Laprise wrote:
> > > Using python3 in dom0, trying to access qubes.Qubes().domains results in the
> > > following error:
> > >
> > > /dev/mapper/control: open failed: Permission denied
> > > Failure to communicate with kernel device-mapper driver.
> > > Incompatible libdevmapper 1.02.136 [...] and kernel driver
> > >
> > > It does work when using 'sudo python3' instead.
> > >
> > > I don't know if this is considered normal behavior or a bug, as I would
> > > normally expect admin objects to be accessible with normal user privs.
> >
> > Yes, that's expected. qubes.Qubes() is meant to be used from qubesd and if
> > you'd like to get knowledge about domains, you should use qubesadmin (even as
> > root). See the qvm-* tools as an example.
> >
>
>
> Is there an analog to the R3.2 function vm.run()? Looking at the difference
> in R4.0 qvm-run source, that doesn't seem to be the case.

Yes, there is `vm.run()`.

- --
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqcAykACgkQ24/THMrX
1yzRDgf/Szkr5vxVE3U60HSWRU3ic5Guku30Ya/QQs4+l6tsfftubzVKPXJ7EwRv
bnLVQbK1pUcTxMbDaP69S9zZ2CALWHybtmQ41yHqvRwlycTs57KZbXPVf01s+f8a
chEpMO367KCFXbMsG7dFQwPlSQhiCsxwq8dVrAtF+yA/m+uTqQSaOwZV4M5EVnf1
Doyf11eCGmkUcib4HLe380KEKqAb2RdLEE0X13RrGDQn6SHwn21CwasX5+G71wGe
DBJIzVS0eqESsRXqeK6EPb+O1zB7QNPIz6t1xEX1nPRjf6NbwItaSuXZnnr123rg
e5UPe46talSK6sEZKDE9wBFqnmQ3Xw==
=8RcF
-----END PGP SIGNATURE-----

[Chris Laprise]

On 03/04/2018 09:30 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sun, Mar 04, 2018 at 05:46:39AM -0500, Chris Laprise wrote:
>> On 02/21/2018 06:20 AM, Wojtek Porczyk wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On Tue, Feb 20, 2018 at 10:45:55PM -0500, Chris Laprise wrote:
>>>> Using python3 in dom0, trying to access qubes.Qubes().domains results in the
>>>> following error:
>>>>
>>>> /dev/mapper/control: open failed: Permission denied
>>>> Failure to communicate with kernel device-mapper driver.
>>>> Incompatible libdevmapper 1.02.136 [...] and kernel driver
>>>>
>>>> It does work when using 'sudo python3' instead.
>>>>
>>>> I don't know if this is considered normal behavior or a bug, as I would
>>>> normally expect admin objects to be accessible with normal user privs.
>>>
>>> Yes, that's expected. qubes.Qubes() is meant to be used from qubesd and if
>>> you'd like to get knowledge about domains, you should use qubesadmin (even as
>>> root). See the qvm-* tools as an example.
>>>
>>
>>
>> Is there an analog to the R3.2 function vm.run()? Looking at the difference
>> in R4.0 qvm-run source, that doesn't seem to be the case.
>
> Yes, there is `vm.run()`.

I've double-checked the source and tried some runs and I think my
initial assessment was right: There's no real analog to R3.2's vm.run()
in R4.0.

If I use vm.run() in R4.0 it waits for the guest process to exit and
then returns the stdout+stderr as byte strings. The guest process will
exit with an error if it asks for input. But in R3.2 vm.run(passio=True)
streamed the guest output to the terminal as it was being written.

This difference shows up in the two versions of qvm-run. Sans
documentation, it looks like you have to create custom event loops in
R4.0 to get the same result as vm.run(passio=True) in R3.2. This leads
me to think that python programs needing to run guest tools in R4.0 are
better off using subprocess.call(qvm-run(passio=True)).

-

Speaking of documentation and APIs, I initially thought (based on public
announcements) that "Qubes Admin API" was what I needed. Then I'm told I
need to use "qubesadmin" which is different. That's confusing. And the
internal API is documented while the app/utility API is not?

Additionally, looking at the tools source there is this pattern of use
that says essentially: Acquire the qubesadmin API via the Qubes parser.
That also seems odd.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hmm, indeed vm.run() use vm.run_service_for_stdio() method.
vm.run_service() returns subprocess.Popen object.

> The guest process will exit with
> an error if it asks for input. But in R3.2 vm.run(passio=True) streamed the
> guest output to the terminal as it was being written.

You can use vm.run_service:
$ python3
Python 3.5.4 (default, Oct 9 2017, 12:07:29)
[GCC 6.4.1 20170727 (Red Hat 6.4.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import qubesadmin
>>> app = qubesadmin.Qubes()
>>> vm = app.domains['sys-net']
>>> p = vm.run_service('qubes.VMShell')
>>> type(p)
<class 'subprocess.Popen'>
>>> p.stdin.write(b'date\n')
5
>>> # this is to tell you don't want more commands, alternatively
>>> # you can write b'command; exit\n' to stdin (especially when you
>>> # want to send some data to the application's stdin
>>> p.stdin.close()
>>> p.stdout.read()
b'Wed Mar 7 00:15:42 CET 2018\n'

And if you want connect it to terminal, just pass stdout=None:

>>> p = vm.run_service('qubes.VMShell', stdout=None)
>>> p.stdin.write(b'date\n')
5
>>> p.stdin.flush()
>>> Wed Mar 7 00:16:01 CET 2018
>>> repr(p.stdout)
'None'

If you want connect stdin from terminal too, then it's a little more
complex, because you need to pass the command first. You can either add
a simple loop that copy stdin (that's what qvm-run does), or enter
command from outside (the thing interacting with this script).

> This difference shows up in the two versions of qvm-run. Sans documentation,
> it looks like you have to create custom event loops in R4.0 to get the same
> result as vm.run(passio=True) in R3.2. This leads me to think that python
> programs needing to run guest tools in R4.0 are better off using
> subprocess.call(qvm-run(passio=True)).
>
> -
>
> Speaking of documentation and APIs, I initially thought (based on public
> announcements) that "Qubes Admin API" was what I needed. Then I'm told I
> need to use "qubesadmin" which is different. That's confusing. And the
> internal API is documented while the app/utility API is not?

There is https://dev.qubes-os.org/projects/core-admin/en/latest/
for qubesd side, and
https://dev.qubes-os.org/projects/core-admin-client/en/latest/ for
client side. The latter one have actual content accessible through
module index.
Generic concepts are explained in the former, client side mostly expose
subset of functions from qubesd (internally through Admin API).

Wojtek, could you add links to both of those sites from
http://dev.qubes-os.org/?
Both are already linked from https://www.qubes-os.org/doc/

> Additionally, looking at the tools source there is this pattern of use that
> says essentially: Acquire the qubesadmin API via the Qubes parser. That also
> seems odd.

- --
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqfO2YACgkQ24/THMrX
1yxnDgf/RMu0ZTIGvbL6Eu92rG07jG3SeFY33V20apco1N300h2ihkKptJ+AhuQs
vzmKXw5VneO/izV5KtMOKieP3KOvf1v8f3x0hr9hsekAqIG85OjxomAIIRsBc2Kq
U99aIoKo5aMKg6SSLw4lc6u8PZX5hGkOU3GmFHhVfID/EyI0YxcGlZZ/vytDCfRb
VWnu5AGrZ204ORo8LYSXQ2/QqdusAUPK52OHJDPdmvlL1rWirImusgZtq15Hxog1
XQwMpgIlUDGa77GF/XBzrpkS68DGoaaq8cBIVyMX4qGRbHp3UiABBkl1Ey0oWeXa
qeygYY6frscoRW4zedpYXpxl2FQrLw==
=Awh4
-----END PGP SIGNATURE-----

[Wojtek Porczyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Mar 07, 2018 at 02:07:25AM +0100, Marek Marczykowski-Górecki wrote:
> There is https://dev.qubes-os.org/projects/core-admin/en/latest/
> for qubesd side, and
> https://dev.qubes-os.org/projects/core-admin-client/en/latest/ for
> client side. The latter one have actual content accessible through
> module index.
> Generic concepts are explained in the former, client side mostly expose
> subset of functions from qubesd (internally through Admin API).
>
> Wojtek, could you add links to both of those sites from
> http://dev.qubes-os.org/?
> Both are already linked from https://www.qubes-os.org/doc/

Done. Sorry for the delay.

- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJavOePAAoJEL9r2TIQOiNRhQ8QAJWWs6XrE5vWoHlXFiHrFuTA
CuhXiZbUyZqFHdRAlkrxS1UW0NSAK3rlYlyrK7Uqgu4o5CX+otpIxSyNdNZqGCJI
Dv8LZnNAoQQstCoxV8r/dlurEukiZ/XwkGi3iTlHKmmCeoBqBwaitTaXm+LEfnzA
C9k/nbYqNSD2lyHOzrC9zZjRFp5xp6n61DDbLbewcS3mgPa9EM6ySpBx8EXmtm2Z
jSZu1grIGtTuhInqlOElp+vhKO9CjjeSQ0K/Cn7/tu0vCKxMAQ6msr5eF/Hkd34e
8onGLi0ErEn1JHbsvYloDFJdRMKAQQjB8/yemiLRueehUmoY7xYTft8E6NbmpBb5
KrC1UGb2ED1V/05dIv5FPoSg2IAPkgzm7+VHf3jcnS/PfKsWmLcXXtNUpA+j06nE
DhNhGFGC0geEmqCgLdDMT2+f48WBLdHvhVla6j3P33abw3+56iSgx2HXnk/GSPK3
xF0ZfSLu0B6bsIot59ArSDmlzEg+BeAG4cnZlRQV5aiRikrAUG29Vht1Iq8Uu9L5
DDJH2CCJkA1QEckEmcWUf4ZWDqjFd2sZwm1XQclHGvAEA72ux/JHxY5lrjOHjHQO
KQzpsos/bAWRwOFv/RJRMp5PX8An/RYRi/CDSoFuPEXqCWad0Y7q54+4/vR7IQiq
mBchsEOrlesxPhHWG7rx
=Npi6
-----END PGP SIGNATURE-----