DispVM savefile creation fails with non-default user login shell

[saironiq]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23 manually updated to 24, other not tested

---

Expected behavior:

DispVM savefile gets updated and a new DVM instance starts.

Actual behavior:

Savefile creation process fails, regular AppVMs work correctly.

Steps to reproduce the behavior:

Change the login shell for the "user" user in template VM to eg. /usr/bin/fish, power off the template VM and try starting eg. firefox in DVM (which triggers the savefile update process).

General notes:

---

Related issues:

[marmarek]

Probably related: #1702
Maybe the solution is not to fix each script not supporting every possible shell, but make sure that scripts are run with POSIX-compliant shell? I think it's about those places (needs -s /bin/sh option):
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qrexec/qrexec-agent.c#L106
https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/appvm-scripts/usrbin/qubes-run-xorg.sh#L69

Needs some testing, especially the first one, because it affect what shell is used for qvm-run - so may result in some unexpected results (qvm-run commands will no longer be using user login shell, but default shell). But maybe this should be the case to fix problems like this? Not sure if this would affect shell used in terminal emulator (xterm, gnome-terminal etc) - hopefully those will still use user login shell (possibly set to some exotic value).

[marmarek]

Probably related: #1702
Maybe the solution is not to fix each script not supporting every possible shell, but make sure that scripts are run with POSIX-compliant shell? I think it's about those places (needs -s /bin/sh option):
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qrexec/qrexec-agent.c#L106
https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/appvm-scripts/usrbin/qubes-run-xorg.sh#L69

Needs some testing, especially the first one, because it affect what shell is used for qvm-run - so may result in some unexpected results (qvm-run commands will no longer be using user login shell, but default shell). But maybe this should be the case to fix problems like this? Not sure if this would affect shell used in terminal emulator (xterm, gnome-terminal etc) - hopefully those will still use user login shell (possibly set to some exotic value).

[unman]

@saironiq This is almost certainly related to #1702.
Like that issue, it's overly broad in statement, since it is perfectly possible to use many shells - sh, dash, bash, rbash and zsh all seem to work.
I think the csh issue in #1702 is because the startup files are not properly sourced for user.
Is the fish issue because it isn't POSIX compliant?
Anyway, can you edit the description to be more specific?

[unman]

@saironiq This is almost certainly related to #1702.
Like that issue, it's overly broad in statement, since it is perfectly possible to use many shells - sh, dash, bash, rbash and zsh all seem to work.
I think the csh issue in #1702 is because the startup files are not properly sourced for user.
Is the fish issue because it isn't POSIX compliant?
Anyway, can you edit the description to be more specific?

[jaseg]

I can confirm this issue with fish. IMHO using su with -s /bin/sh would be the cleanest fix here. I don't think you can necessarily make assumptions about the user's default login shell, which su is calling here. So an explicit override to the /bin/sh symlink explicitly points this to the user's POSIX shell of choice (such as bash, dash or others).

[jaseg]

I can confirm this issue with fish. IMHO using su with -s /bin/sh would be the cleanest fix here. I don't think you can necessarily make assumptions about the user's default login shell, which su is calling here. So an explicit override to the /bin/sh symlink explicitly points this to the user's POSIX shell of choice (such as bash, dash or others).

[unman]

using su -s /bin/sh is not the solution because it does indeed break qvm-run and affects the shell used in terminal emulator, which negates the point in changing to a different shell.
NB. as in #1702 most shells work fine - tcsh and fish are problematic, but fish is better in that only disposableVMs are affected.

[unman]

using su -s /bin/sh is not the solution because it does indeed break qvm-run and affects the shell used in terminal emulator, which negates the point in changing to a different shell.
NB. as in #1702 most shells work fine - tcsh and fish are problematic, but fish is better in that only disposableVMs are affected.

[unman]

@marmarek This is specific to fish - and in my experience that doesnt work properly as appVM despite what OP said, in that a second prompt is required to get xterm to open.
As far as creating a dispVM Template,the qubes-prepare-saved-domain,sh script runs as far as qubesdb-watch -d $1 /qubes-used-mem - that's where it sticks. Any idea what could be causing that?

[unman]

@marmarek This is specific to fish - and in my experience that doesnt work properly as appVM despite what OP said, in that a second prompt is required to get xterm to open.
As far as creating a dispVM Template,the qubes-prepare-saved-domain,sh script runs as far as qubesdb-watch -d $1 /qubes-used-mem - that's where it sticks. Any idea what could be causing that?

[marmarek]

I guess it's about #1702 - /qubes-used-mem is written after X session is started (it's waiting on /etc/qubes-rpc/qubes.WaitForSession in prepare-dvm.sh).

…

-- 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]

I guess it's about #1702 - /qubes-used-mem is written after X session is started (it's waiting on /etc/qubes-rpc/qubes.WaitForSession in prepare-dvm.sh).

…

-- 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?