`sudo qubes-dom0-update` results in broken updates with `script: cannot open typescript: Permission denied`

adrelanos commented 1 year ago

Qubes OS release

R4.2

Brief summary

Running sudo qubes-dom0-update results in:

script: cannot open typescript: Permission denied

And no update. Nothing beyond that point.

Steps to reproduce

Qubes R4.2 installation
testers updates
sudo qubes-dom0-update

Expected behavior

No such error.

Actual behavior

script: cannot open typescript: Permission denied

marmarek commented 1 year ago

Do you use sys-firewall or sys-whonix as updatevm? Can you open a terminal there and try to create any file in the home directory?

marmarek commented 1 year ago

BTW, besides finding why Permission denied happens, the actual fix is to not try to create typescript file at all.

adrelanos commented 1 year ago

Using sys-firewall based on fedora-38.

adrelanos commented 1 year ago

Workaround:

sudo qubes-dom0-update | xargs echo

(Could also edit the script to avoid using script but that seemed simpler.)

adrelanos commented 1 year ago

Not a great workaround. Needs some extra parameter because it doesn't allow to confirm yes/no.

adrelanos commented 1 year ago

sys-firewall in home folder (just opened a terminal):

touch a

touch: cannot touch 'a': Permission denied

All files in home folder are owned by root. Which is weird, I didn't make such a change. I guess the home folder permissions are a separate bug?

Is there a Qubes OpenQA unit test for basic linux file permission checks?

As far as this issue here:

Either don't use script.
Or use an alternative to script.
Have script write to a folder which is reasonably guaranteed to have write access.
For defense in depth, use chown beforehand?

But then I suppose the script is running as root anyhow and then I am wondering why root would get permission denied.

marmarek commented 1 year ago

Is there a Qubes OpenQA unit test for basic linux file permission checks?

There is several that use qubes-dom0-update, and it works...

Have script write to a folder which is reasonably guaranteed to have write access.

Well, home folder is such place, the fact that user doesn't have write access to its own home is very wrong.

But then I suppose the script is running as root anyhow and then I am wondering why root would get permission denied.

No, it isn't. Updates are downloaded as normal user.

So, there are two things to fix here:

fix /home/user permissions
adjust script call to not create a file (write to /dev/null)

marmarek commented 1 year ago

Do you see any startup errors in sys-firewall, especially related to qubes-mount-dirs.service?

adrelanos commented 1 year ago

The solution you've implemented looks very nice, simple. Much more robust than figuring out any writable folder location.

Do you see any startup errors in sys-firewall, especially related to qubes-mount-dirs.service?

No.

sys-firewall is based on default-dvm which in turn is based on fedora-38 Template.

sudo journalctl --boot -u qubes-mount-dirs | cat

Jul 02 08:05:25 fedora mount-dirs.sh[307]: Private device management: checking /dev/xvdb Jul 02 08:05:25 fedora mount-dirs.sh[307]: Private device management: fsck.ext4 of /dev/xvdb succeeded Jul 02 08:05:25 fedora systemd[1]: Starting qubes-mount-dirs.service - Initialize and mount /rw and /home... Jul 02 08:05:25 fedora mount-dirs.sh[337]: Checking /rw Jul 02 08:05:25 fedora mount-dirs.sh[337]: Private device size management: enlarging /dev/xvdb Jul 02 08:05:25 fedora mount-dirs.sh[337]: Private device size management: resize2fs of /dev/xvdb succeeded Jul 02 08:05:25 fedora mount-dirs.sh[337]: Finished checking /rw Jul 02 08:05:25 fedora mount-dirs.sh[305]: Mounting /rw/home onto /home Jul 02 08:05:25 fedora mount-dirs.sh[305]: Mounting /rw/usrlocal onto /usr/local Jul 02 08:05:25 fedora mount-dirs.sh[371]: /var/spool/cron is not a symlink Jul 02 08:05:25 fedora mount-dirs.sh[371]: Bind mounting /rw/bind-dirs/var/spool/cron onto /var/spool/cron Jul 02 08:05:25 fedora systemd[1]: Finished qubes-mount-dirs.service - Initialize and mount /rw and /home.

No failed systemd units.

sudo systemctl --failed list-units

UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed.

adrelanos commented 1 year ago

It turned out when opening a GNOME Terminal in sys-firewall it opens the root folder / instead of /home/user. Obviously all files in / are owned by root which is of course correct.

I got confused by the change by GNOME Terminal or not sure where this was changed which folder gets opened by default when starting a terminal.

Therefore my prior thought that the folder permissions in /home/user are wrong. There is no such issue. Permissions in /home/user are correct.

There was only 1 issue (dunno why that happened) which you now fixed. Case closed.

QubesOS / qubes-issues