generic qubes qrexec rpc '.d' "/etc/qubes-rpc.d" drop-in folder

[adrelanos]

As @marmarek and I agreed in #1663 (comment)...

"/etc/qubes-rpc.d" should be implemented as a generic solution.

One use case would be having several suspend / resume scripts. (#1663) These are required for Whonix to get time synchronization and Tor back on track after resume (#1764) or getting a VPN connections re-established (#1663).

Likely will be other /etc/qubes-rpc/rps's where one might wish to have several handlers. Being invoked before/after the stock one. To allow modifying the handlers without interfering with upstream Qubes default qubes-rpc script upgrades.

Idea A)

• /etc/qubes-rpc/qubes.OpenInVM.pre.d/
• /etc/qubes-rpc/qubes.OpenInVM.post.d/

An alternative B) might be.

• /etc/qubes-rpc.d/qubes.OpenInVM.pre/
• /etc/qubes-rpc.d/qubes.OpenInVM.post/

An alternative C) might be.

• /etc/qubes-rpc.d/qubes.OpenInVM/10_user_pre.sh
• /etc/qubes-rpc.d/qubes.OpenInVM/20_special_qubes_addon_pre.sh
• /etc/qubes-rpc.d/qubes.OpenInVM/30_qubes_default.sh
• /etc/qubes-rpc.d/qubes.OpenInVM/40_special_qubes_addon_post.sh
• /etc/qubes-rpc.d/qubes.OpenInVM/50_user_post.sh

The above names are not fixed. These are just example names for illustration. Executing these in the usual lexical order.

Executing and executable script / program ending with *.sh. (To avoid issues with backup files ending with ~, *.dpkg-old etc.)

[marmarek]

Should this allow also disabling Qubes original handler? I think about cases like qubes.SetDateTime in Whonix. @adrelanos

[marmarek]

Should this allow also disabling Qubes original handler? I think about cases like qubes.SetDateTime in Whonix. @adrelanos

[adrelanos]

Marek Marczykowski-Górecki:

Should this allow also disabling Qubes original handler? I think about cases like qubes.SetDateTime in Whonix. @adrelanos

Ideally, yes. Realistically, probably not.

[ Because the only design I can think off where you can do that is not
pretty. (sourcing shell functions were you can overwrite existing ones
with lexically higher ordering. 40_qubes-whonix.sh overwriting the
default shell function in 30_qubes-default.sh. But perhaps you had a
better design in mind. ]

[ Whonix's current solution with (Debian specific) config-package-dev
displace is okay-ish. ]

Should this allow also disabling Qubes original handler? I think about
cases like qubes.SetDateTime in Whonix. @adrelanos

Perhaps an okay-ish solution from the users or integrators perspective
would be 'chmod -x /path/to/original-qubes-handler'?

[adrelanos]

Marek Marczykowski-Górecki:

Should this allow also disabling Qubes original handler? I think about cases like qubes.SetDateTime in Whonix. @adrelanos

Ideally, yes. Realistically, probably not.

[ Because the only design I can think off where you can do that is not
pretty. (sourcing shell functions were you can overwrite existing ones
with lexically higher ordering. 40_qubes-whonix.sh overwriting the
default shell function in 30_qubes-default.sh. But perhaps you had a
better design in mind. ]

[ Whonix's current solution with (Debian specific) config-package-dev
displace is okay-ish. ]

Should this allow also disabling Qubes original handler? I think about
cases like qubes.SetDateTime in Whonix. @adrelanos

Perhaps an okay-ish solution from the users or integrators perspective
would be 'chmod -x /path/to/original-qubes-handler'?

[marmarek]

On Mon, Mar 21, 2016 at 02:34:10AM -0700, Patrick Schleizer wrote:

Marek Marczykowski-Górecki:

Should this allow also disabling Qubes original handler? I think about cases like qubes.SetDateTime in Whonix. @adrelanos

Ideally, yes. Realistically, probably not.

[ Because the only design I can think off where you can do that is not
pretty. (sourcing shell functions were you can overwrite existing ones
with lexically higher ordering. 40_qubes-whonix.sh overwriting the
default shell function in 30_qubes-default.sh. But perhaps you had a
better design in mind. ]

[ Whonix's current solution with (Debian specific) config-package-dev
displace is okay-ish. ]

I see. I don't know any Fedora solution for that, but I'm ok with that.

Perhaps an okay-ish solution from the users or integrators perspective
would be 'chmod -x /path/to/original-qubes-handler'?

That will be hard in practice. Because every handler may have some
different content. There is no strict requirement that /etc/qubes-rpc/*
file contains only a path to the handler, the whole script may be there
(see /etc/qubes-rpc/qubes.DetachPciDevice).
Also +x/-x on the /etc/qubes-rpc/sth file itself already have a meaning:
whether should it be started directly (exec /etc/qubes-rpc/sth), or
through shell (exec /bin/sh /etc/qubes-rpc/sth). For compatibility with
R2 and earlier (most of Qubes addons like split-gpg are exactly the same
for every Qubes version).
Running non-executable files through /bin/sh there is something
inconvenient also for other reasons, but I'd really like to keep this
compatibility as long as possible, to not break existing addons
(including user custom one).

To sum up: not going to provide generic solution for disabling original
handler.

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]

On Mon, Mar 21, 2016 at 02:34:10AM -0700, Patrick Schleizer wrote:

Marek Marczykowski-Górecki:

Should this allow also disabling Qubes original handler? I think about cases like qubes.SetDateTime in Whonix. @adrelanos

Ideally, yes. Realistically, probably not.

[ Because the only design I can think off where you can do that is not
pretty. (sourcing shell functions were you can overwrite existing ones
with lexically higher ordering. 40_qubes-whonix.sh overwriting the
default shell function in 30_qubes-default.sh. But perhaps you had a
better design in mind. ]

[ Whonix's current solution with (Debian specific) config-package-dev
displace is okay-ish. ]

I see. I don't know any Fedora solution for that, but I'm ok with that.

Perhaps an okay-ish solution from the users or integrators perspective
would be 'chmod -x /path/to/original-qubes-handler'?

That will be hard in practice. Because every handler may have some
different content. There is no strict requirement that /etc/qubes-rpc/*
file contains only a path to the handler, the whole script may be there
(see /etc/qubes-rpc/qubes.DetachPciDevice).
Also +x/-x on the /etc/qubes-rpc/sth file itself already have a meaning:
whether should it be started directly (exec /etc/qubes-rpc/sth), or
through shell (exec /bin/sh /etc/qubes-rpc/sth). For compatibility with
R2 and earlier (most of Qubes addons like split-gpg are exactly the same
for every Qubes version).
Running non-executable files through /bin/sh there is something
inconvenient also for other reasons, but I'd really like to keep this
compatibility as long as possible, to not break existing addons
(including user custom one).

To sum up: not going to provide generic solution for disabling original
handler.

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?