[Whonix-devel] [qubes-devel] Require script to run immed. after /rw mount

Tue Apr 18 11:46:00 CEST 2017

Marek Marczykowski-Górecki:
> On Tue, Apr 18, 2017 at 01:06:00AM +0000, Patrick Schleizer wrote:
>> Marek Marczykowski-Górecki:
>>> On Mon, Apr 17, 2017 at 11:06:00PM +0000, Patrick Schleizer wrote:
>>>> Marek Marczykowski-Górecki:
>>>>> On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
>>>>>>> Alternately, mount-dirs.sh could have
>>>>>>> a hook that points to a specific user script in /etc.
>>>>>
>>>>>> User script sounds a bit limited. What about something a little more
>>>>>> flexible?
>>>>>
>>>>>> Untested pseudo code:
>>>>>
>>>>>> if [ -d /etc/qubes/mount-dirs-post.d ]; then
>>>>>>    run-parts /etc/qubes/mount-dirs-post.d
>>>>>> fi
>>>>>
>>>>> IMO this is the way to go. In addition to your VM hardening scripts,
>>>>> this could be used also for some /rw initialization, beyond /etc/skel.
>>>>> AFAIR there was a need for similar thing to copy Tor Browser there.
>>>>>
>>>>> As for implementation - do we want it in /etc, /usr/lib, or both (so
>>>>> files in /etc could override /usr/lib)?
>>>
>>>> Yes in both. Actually in all three. I.e. /etc/, /usr/lib and in
>>>> /usr/local (/rw) to make it complete.
>>>
>>> No, the whole point about this script is to run something _before_
>>> anything gets processed/run from /rw.
> 
>> Right. (Scratch that /rw idea.)
> 
>>>>> But having both means we can't
>>>>> use run-parts :(
>>>
>>>> Why not just use above "Untested pseudo code" three times with the
>>>> different dirs? :)
>>>
>>> Because it will not allow to disable/override a script in /usr/lib by
>>> placing a script with the same name in /etc.
> 
>> Alright. We can have that feature. Then perhaps let's use bash `source`.
> 
>> Each snipped could define an entry function named
>> number_main_drop-in-name or so. For example.
> 
>> /usr/lib/qubes-mount-dirs.d/50_bind_dirs.conf:
> 
>> 50_main_bind_dirs() {
>>    /path/to/actual/script
>> }
> 
>> To disable that, a lexically higher configuration file could just do.
> 
>> /etc/qubes-mount-dirs.d/50_bind_dirs.conf:
> 
>> 50_main_bind_dirs() {
>>    true
>> }
> 
>> Then the mount-dirs.sh script could `source` all these `.conf`s, and use
>> `compgen` to get a list of function names, match these for `_main_`.
>> Then run these functions in lexical order.
> 
>> Does that look good? If needed, I could as well describe that better or
>> write some pseudo code for that. I like this override / configureability
>> stuff.
> 
> IMO forcing people to writing a bash function in such script is a bad
> idea.

Okay, I see. I think the people wishing to implement such overrides
would be capable to do it as per developer documentation but it's of
course up to you.

> First of all, many will not do that, breaking this override
> schema. If more elaborative script is needed anyway, lets work on full
> files, like this:
> 
>     IFS=$'\n'
>     readarray -t files_basename < <(
>         find /usr/lib/qubes-mount-dirs.d /etc/qubes-mount-dirs.d 
>         -type f -executable -printf '%f\n' | sort | uniq)
> 
>     for f in "${files_basename[@]}"; do
>         if [ -x "/etc/qubes-mount-dirs.d/$f" ]; then
>             "/etc/qubes-mount-dirs.d/$f"
>         elif [ -x "/usr/lib/qubes-mount-dirs.d/$f" ]; then
>             "/usr/lib/qubes-mount-dirs.d/$f"

>         endif

          fi

>     done

That would make it easier for users to add a single override, better
usability from that perspective.

However, would not be ideal for developers. We'd loose flexibility.
Since then scripts could only be overwritten by users. Would not be a
proper override system for packages / developers.

Cheers,
Patrick