Hi, I’m trying to edit a file in another VM but I keep getting access denied as you can see from the screenshot:
And I was wondering if anybody might know why this is happening?
Regards
Nick
HI @glosnick
I’m afraid I cant see your screenshot, so I am probably missing
essential detail.
You say you get “access denied” - if this is an error generated in the
“another” qube, then check permissions in the qube - the file should be
writable by user.
If you are trying to edit a file in another VM using (say) the menu item
"Edit in Disposable VMin Nautilus, then it's likely that the qrexec policy settings need correction. The default settings are in /etc/qubes/policy.d/90-default.policy The policy you want is qubes.OpenInVM The default setting should allow you to open in a disposable without asking. If you have changed this for any reason, then you may find that your new settings are blocking the edit. So: Check you have a default_dispvm set for the sending qube. Check you have a line that says:qubes.OpenInVM * SENDING_QUBE @dispvm allow` in 30-user.policy
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
Yours looks like a pretty good guess @unman, the screenshot mainly shows a notification that says: Denied qubes.OpenInVM from work to @dispVM. 
@glosnick The images don’t make it to the folks who use the mail version of the forum, that’s why @unman can’t see your screenshot. You did nothing wrong when attaching it.
That being said, it’s always good to add a short description of any image you attach to your posts 
Oh!!! I see, who knew. But thanks for letting me know and I shall endeavour to remember in future.
Hi, thanks for getting back to me. The error wasn’t generated in another Qube but came up as a notification underneath the main toolbar on my desktop. I tried write clicking on the file in the work VM and basically giving write options to all users but that failed. I’ve tried giving my user root privileges by editing the /etc/passwd file and giving ‘bob’ 0 for both UID and GID but again this didn’t work. I had a look in 90-default policy and this is a link to that file:
I hope that everybody can view the file.
I also don’t appear to have a 30-user.policy file. I’ve made very few changes to Qubes since installation so don’t really understand why this would be a problem for a fresh install. So does this mean that I need to create a 30-user.policy with the required line before my problem can be solved?
Regards
Nick
Just in case you can’t see the link:
## Do not modify this file, create a new policy file with a lower number in the
## filename instead. For example `30-user.policy`.
###
### Default qrexec policy
###
## File format:
## service-name|* +argument|* source destination action [options]
## Note that policy parsing stops at the first match.
# policy.RegisterArgument should be allowed only for specific arguments.
policy.RegisterArgument * @anyvm @anyvm deny
policy.RegisterArgument * @anyvm dom0 deny
# WARNING: The qubes.ConnectTCP service is dangerous and allows any
# qube to access any other qube TCP port. It should be restricted
# only to restricted qubes. This is why the default policy is 'deny'
# Example of policy: qubes.ConnectTCP +22 mytcp-client @default allow target=mytcp-server
qubes.ConnectTCP * @anyvm @anyvm deny
# VM advertise its supported features
qubes.FeaturesRequest * @anyvm dom0 allow
# Windows VM advertise installed Qubes Windows Tools
qubes.NotifyTools * @anyvm dom0 allow
# File copy/move
qubes.Filecopy * @anyvm @anyvm ask
# Get current date/time
qubes.GetDate * @tag:anon-vm @anyvm deny
qubes.GetDate * @anyvm @anyvm allow target=dom0
# Get slightly randomized date/time
qubes.GetRandomizedTime * @anyvm dom0 allow
# Convert image to a safe format, also, allows to get an image (icon) file from a VM
qubes.GetImageRGBA * @anyvm @dispvm allow
qubes.GetImageRGBA * @anyvm @anyvm ask
# Notify about available updates
qubes.NotifyUpdates * @anyvm dom0 allow
# Open a file in a VM
qubes.OpenInVM * @anyvm @dispvm allow
qubes.OpenInVM * @anyvm @anyvm ask
# Open URL in a VM
qubes.OpenURL * @anyvm @dispvm allow
qubes.OpenURL * @anyvm @anyvm ask
# Start application using its menu entry (only applications with menu entries
# are allowed, no arbitrary command). Argument is an application name (in case
# of Linux, basename of .desktop file from /usr/share/applications or similar
# location).
qubes.StartApp * @anyvm @dispvm allow
qubes.StartApp * @anyvm @anyvm ask
# HTTP proxy for downloading updates
# Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy * @tag:whonix-updatevm @default allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy * @tag:whonix-updatevm @anyvm deny
# Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-net
qubes.UpdatesProxy * @anyvm @anyvm deny
# WARNING: The qubes.VMShell service is dangerous and there are really few
# cases when it could be safely used. Especially when policy set to "ask" you
# have no way to know for sure what command(s) will be called. Compromissed
# source VM can substitute the command. Allowing one VM to execute
# qubes.VMShell over the other VM allows the former to TAKE FULL CONTROL over
# the later. In most cases this is not what we want!
#
# Instead we should be using task-specific qrexec services which provide
# assurance as to what program will be responding to the (untrusted) VM
# requests.
#
# It is, however, safe, in most cases, to allow ultimate control of the
# creating AppVM over the DisposableVM it creates as part of the qrexec service
# invocation. That's why by default we have "@anyvm @dispvm allow" rule. Note
# that it does _not_ allow any AppVM to execute qubes.VMShell service over any
# DispVM created in the system -- that would obviously be wrong. It only allows
# qubes.VMShell service access to the AppVM which creates the DispVM as part of
# this very service invocation.
#
# See e.g. this thread for some discussion:
# https://groups.google.com/d/msg/qubes-users/xnAByaL_bjI/3PjYdiTDW-0J
qubes.VMShell * @anyvm @dispvm allow
qubes.VMShell * @anyvm @anyvm deny
# WARNING: qubes.VMRootShell has similar risks as qubes.VMExec
# Add "user=root" option to any ask or allow rules.
qubes.VMRootShell * @anyvm @anyvm deny
# WARNING: The qubes.VMExec service is dangerous and there are really few
# cases when it could be safely used. Contrary to qubes.VMShell, when policy is
# set to "ask", the command to be executed is visible in the confirmation
# prompt. But once allowed, the source VM have full control over the command
# standard input/output. Allowing one VM to execute qubes.VMExec over the
# other VM allows the former to TAKE FULL CONTROL over the later. In most cases
# this is not what we want!
#
# Instead we should be using task-specific qrexec services which provide
# assurance as to what program will be responding to the (untrusted) VM
# requests.
#
# It is, however, safe, in most cases, to allow ultimate control of the
# creating AppVM over the DisposableVM it creates as part of the qrexec service
# invocation. That's why by default we have "@anyvm @dispvm allow" rule. Note
# that it does _not_ allow any AppVM to execute qubes.VMExec service over any
# DispVM created in the system -- that would obviously be wrong. It only allows
# qubes.VMExec service access to the AppVM which creates the DispVM as part of
# this very service invocation.
#
# See e.g. this thread for some discussion:
# https://groups.google.com/d/msg/qubes-users/xnAByaL_bjI/3PjYdiTDW-0J
qubes.VMExec * @anyvm @dispvm allow
qubes.VMExec * @anyvm @anyvm deny
# WARNING: qubes.VMExecGUI has similar risks as qubes.VMExec
qubes.VMExecGUI * @anyvm @dispvm allow
qubes.VMExecGUI * @anyvm @anyvm deny
Formatting note
I added a code block to make the file easier to read. That's done with backticks ```. The edit history makes it look like a big change, but it was thise three backticks above and below the block of code, and removing the empty blockquote at the end. Three lines changed in total.The required policies are already in your default policy file (90-default.policy).
These lines:
# Open a file in a VM
qubes.OpenInVM * @anyvm @dispvm allow
qubes.OpenInVM * @anyvm @anyvm ask
You don’t have a 30-user.policy file because you didn’t make any change to the RPC policies rules.
Look inside this directory: /etc/qubes-rpc/policy if you have a file named qubes.OpenInVM.
If you have, it probably contain somethings like: $anyvm $dispvm deny.
This file use the old policies format, you can remove it (or rename it to qubes.OpenInVM.bak).
and, as Unman said:
You can read more about RPC policies in the doc:
Make sure to also read the new policy format article, the link is in the first line of the doc.
Apologies that it took me so long to get back to this thread. I’m still hoping somebody might see this reply and respond, fingers crossed. Anyway, so if I have the required lines in my 90-default.policy why does it still not work. I look in /etc/qubes-rpc/policy but there did not seem to be a qubes.OpenInVM files. So as unman said I should check that I have a default_dispvm set for the sending qube. But how would I check this and where. Sorry if I’m just being thick.
Regards
Nick
Ha ha!!! Think I managed to answer my own question:
The default system wide disposable template can be changed with qubes-prefs default_dispvm. By combining the two, choosing Open in disposable from inside an app qube will open the document in a disposable based on the default disposable template you specified.
You can change this behavior for individual qubes: in the Application Menu, open Qube Settings for the qube in question and go to the “Advanced” tab. Here you can edit the “Default disposable” setting to specify which disposable template will be used to launch disposables from that qube. This can also be changed from the command line with:
So I followed the above and changed the default disposable setting to fedora-37-dvm and I no longer got the accessed denied warning. Yay me and a big thank you to Unman for the fix.
Regards
Nick
1 Like