bug#47735: Non-absolute paths in mariadb scripts

bug#47735: Non-absolute paths in mariadb scripts

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Hi Guix,

As part of <https://issues.guix.gnu.org/47704>, it was discovered
some shell scripts in the mariadb package (e.g. wsrep_sst_rsync)
refer to programs *not* by absolute name.

These programs come from iproute, coreutils, gawk, grep
and mariadb itself.  It seems some substitutions are in order.

Some complications:
some of these scripts are only required in certain configurations.
It's not ideal to increase the closure with rsync and xbcrypt if
they turn out not to be needed ...

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#47735: Non-absolute paths in mariadb scripts

[david larsson]

On 2021-04-12 22:14, Maxime Devos wrote:
> Hi Guix,
> 
> As part of <https://issues.guix.gnu.org/47704>, it was discovered
> some shell scripts in the mariadb package (e.g. wsrep_sst_rsync)
> refer to programs *not* by absolute name.
> 
> These programs come from iproute, coreutils, gawk, grep
> and mariadb itself.  It seems some substitutions are in order.
> 
> Some complications:
> some of these scripts are only required in certain configurations.
> It's not ideal to increase the closure with rsync and xbcrypt if
> they turn out not to be needed ...
> 
> Greetings,
> Maxime.

Adding to this, so far we've we discussed possible fixes:

1. Absolutize all invocations in the sripts using (substitute* 
procedure.
   - drawback: maintenance hassle.

2. Adding (define %default-environment-variables to the mysql-service 
and append this to the list-argument of the #:environment-variables 
keyword in the make-forkexec-constructor procedure.
   - drawback: doesn't actually fix the mysql package, just the service.

3. Adding a line: 
"PATH=<absolute-path-to-awk>:<absolute-path-to-grep>:<etc..>" in the 
scripts.
   - Not the most elegant solution, but possibly the best one; not too 
much maintenance and actually fixes both the package and the service.
   - drawback: It would also increase the closure size of the mysql 
package. Security issues?

Another option, perhaps, would be to have a mysql-minimal package (as 
the package is today) and a regular mysql package ("mysql-full" with the 
increase closure size), and you can use whichever package you need in 
the mysql-service.

I don't know which solution I would vote for...

Best regards,
David L