Since 4.0 is still supported, is it true that they’re “no-longer-existent qrexec policies”? That is, don’t they still exist in 4.0? I’m afraid that removing that doc content could harm 4.0 users who are still relying on it. Folks who have decided not to upgrade yet are likely to be those who particularly value stability and reliability, so pulling the rug out from under them seems especially bad.
I also have to confess that I’m not familiar enough with those qrexec policy changes yet to be able to tell exactly which parts of those pages no longer apply in 4.1. Perhaps you might be willing to open a doc PR?
To be honest, I’m not entirely sure I’m using the right technical term to refer to the issue, but the issue definitely exists nonetheless.
For example, on the passwordless root page:
Adding Dom0 “VMAuth” service:
[root@dom0 /]# echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
[root@dom0 /]# echo "@anyvm dom0 ask,default_target=dom0" \
>/etc/qubes-rpc/policy/qubes.VMAuth
(Note: any VMs you would like still to have passwordless root access (e.g. Templates) can be specified in the second file with “<vmname> dom0 allow”)
The /etc/qubes-rpc/qubes.VMAuth and /etc/qubes-rpc/policy/qubes.VMAuth mentioned here no longer exist in R4.1, and creating it doesn’t solve the issue as the system no longer uses it.
Similarly, in the Yubikey documentation, the user is supposed to:
First configure the qrexec service. Create /etc/qubes-rpc/custom.LockScreen with a simple command to lock the screen. In the case of xscreensaver (used in Xfce) it would be:
I haven’t tried this out myself, but chances are the qrexec changes have made this outdated in the same way it made the previous verified example outdated.
I don’t mean to antagonize, but R4.1 is the current release and support for R4.0 will end in around five months. New users who will be the biggest beneficiaries of the documentation (in terms of both the amount of help and the amount of people helped) will naturally adopt the newer version. This also isn’t to say that older documentation should be immediately scrapped–keeping them in the same documentation under a subsection or tagged with a warning would work.
Actually, the system does use it, or at least it should.
There is backwards compatibility in 4.1 so that the old policy files
should be recognised.
Look at /etc/qubes/policy.d/35-compat.policy
The change in 4.1 is to the main location of the policy file, and as
said above, there is transitional support for the old policy location.
So there’s no reason to think that this would be outdated.
I don’t have a Yubikey with me, so cant check this.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Thanks for getting back on this. I went and thoroughly tested configuring sudo prompt on Qubes R4.1 with Debian 11. I used @Tasket’s configure-sudo-prompt, which faithfully automates the non-dom0 portion of the setup, while using the current version of the documentation as reference.
I created the qubes.VMAuth files as per instructions.Testing showed that sudo prompt appears, but when used fails with dom0 notification:
Failed: qubes.VMAuth
Failed to execute qubes.VMAuth (from vm-test to dom0)
As a bonus I went through every single relevant file within Debian-11 to confirm that the changes by the script match the instructions.
/etc/pam.d/common-auth
/etc/sudoers.d/qubes
/etc/pam.d/su.qubes
The one difference is /etc/pam.d/su.qubes no longer exists, but I wasn’t able to find a substitute containing auth sufficient pam_permit.so to comment out. This might linked to qrexec changes and causing all of this.
I also confirmed that the following files no longer exist as per instructions:
I have tested this, and bar a minor change in the name of one file, the
instructions (for a dom0 prompt to get root) work fine in 4.1
The qrexec policy files work just as expected, given the compatibility
framework in 4.1.
I don’t know if it would be best to write the 4.1 instructions to use
the “correct” policy file locations - that would then need a smaller
change for 4.2 when it comes.
Otherwise it would just need a PR for that name change in instructions for 4.1 @adw - thoughts?
As I’ve said, there’s no reason why the Yubikey instructions wouldn’t
work, as is.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
I followed the instructions using a fresh R4.1.0 (the actual release via iso, and not the beta) and a fresh Debian-11-Minimal (with qubes-core-agent-passwordless-root installed) and ended up with a sudo prompt that doesn’t work. I even went and double-checked that everything is as they should be.
In R4.0 the file /etc/qubes-rpc/qubes.VMAuth exists by default and is already configured the way it should be.
In R4.1 this file doesn’t exist by default; when the user follows the documentation and creates the file via echo, it isn’t created as an executable. This is why the sudo prompt fails on the dom0 side of things.
Adding one line to the documentation should fix everything:
I don’t have a Github account so I’ll leave the commit to a kind passerby. This finding means @Tasket’s configure-sudo-prompt shouldn’t need modification for R4.1. Additionally, all of the qubes-scripts I’ve tested seem to work perfectly in R4.1.
Also, /etc/pam.d/su.qubes no longer exists, at least in debian-11-minimal, and its absence has no effect on the prompt, so this part of the documentation can be safely removed.
The solution above worked until it and some other qrexec policies I modified suddenly just stopped working even though the files have been confirmed to be untouched.
Replaces the contents of a file called /etc/qubes-rpc/qubes.VMAuth with:
/usr/bin/echo 1
If that’s the command you’re referring to @dro212, you shouldn’t have "only “1"”, but rather that entire line. Might you have mis-typed the command? (Caution: since /usr/bin/echo could itself be interpreted as a command, quotes matter!)