search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
535 stars 47 forks source link

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

Open adrelanos opened 8 years ago

adrelanos commented 8 years ago

As @marmarek and I agreed in https://github.com/QubesOS/qubes-issues/issues/1663#issuecomment-196783899...

"/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)

An alternative B) might be.

An alternative C) might be.

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 commented 8 years ago

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

adrelanos commented 8 years ago

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 commented 8 years ago

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?