bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[Gary Johnson via Bug reports for GNU Guix <bug-guix@gnu.org>]

Hi Guix,

The bug in which home-mcron-service-type overwrites the user's PATH with a single non-existent directory makes mcron completely unusable on foreign distros. Since it seems to me that foreign distros are the main target for home mcron services (since there is no global shepherd to run mcron for you), this really should be elevated to a high priority bug.

I see that earlier in this message thread questions were raised as to what the proper behavior should be for setting the PATH, but I think we can say with no reservations that setting PATH to a directory that is guaranteed not to exist on a foreign distro is definitely not the correct choice. Also, setting it explicitly to directories not managed by Guix profiles or Guix Home like /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and so on also isn't a great idea since users of the home-cron-service-type are obviously using it through Guix Home. The correct choice IMHO is to follow the principle of least surprise here.

Namely, in the Guix info pages at "(guix)Top > Home Configuration > Home Services > Mcron Home Service", we have section "13.3.3 Scheduled User’s Job Execution". Under home-mcron-configuration, we see the "jobs" field, which links us to "mcron job specifications(mcron)" for explanations of how to define our mcron jobs.

Following this link on to "(mcron)Top > Syntax > Guile Syntax", we encounter section "3.1.1 Job specification". The final paragraph in this section reads as follows:

> The second argument to the 'job' function can be either a string, a list, or a function. The command is executed in the home directory and with the UID of USER. If a string is passed, it is assumed to be shell script and is executed with the user's default shell. If a list is passed it is assumed to be Scheme code and is _eval_'d as such. A supplied function should take exactly zero arguments, and will be called at the pertinent times.

Note the third sentence:

"If a string is passed, it is assumed to be shell script and is executed with the user's default shell."

Reading that, I (and I imagine most mcron users) will infer that the environment my job command will run in will be the same as what I would get if I spawned a new non-interactive shell. That is, the new mcron job shell should inherit all the environment variables that were defined when the user's sheperd process was launched (which will be everything loaded into a standard login shell, such as /etc/profile, ~/.bash_profile, and everything that they source like Guix Home's ~/.profile) plus a fresh run of ~/.bashrc (or the equivalent non-interactive shell config file for whatever shell the user has chosen). It seems to me that this is what most people reading the manual are going to understand (and therefore expect) and that it is the most compatible with Guix Home since all environment variables set in the `home-environment` will be available to our mcron jobs.

However, with the current behavior, it appears that the shell spawned for the user mcron job actually reads /etc/profile and ~/.profile (but not ~/.bash_profile or ~/.bashrc). The ~/.profile file sources ~/.guix-home/setup-environment and then runs ~/.guix-home/on-first-login. While being very confusing and unintuitive (because my default shell is /bin/bash and is reported correctly within the mcron job environment as "SHELL=/bin/bash"), this at least loads ~/.guix-home/profile/etc/profile and ~/.guix-profile/etc/profile. However, since mcron then promptly erases the correctly built up PATH from Guix Home and the user's main Guix profile, the commands executed in this PATH-less shell are borked.

As others in this thread have previously noted, with the current behavior of providing an unintuitive and completely unusable PATH to user mcron jobs, the home-mcron-service-type is largely unusable except for the simplest commands in which you can use ungexp package directory expansion to build up the locations of a Guix-installed executable. However, if any job command ever needs to shell out to any other executable, it will not be found, and the job will crash and burn.

Please fix this, folks. And if you aren't willing to implement the intuitive, documented, and Guix Home compatible shell behavior described above, please at the very least extend the "job" function with a keyword to allow us to pass environment variables into the mcron job shell along with something like the "(default-environment-variables)" function that is available for shepherd service "start" functions.

Thanks!
  Gary

-- 
GPG Key ID: C4FBEDBD
Use `gpg --search-keys tracker@disroot.org' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html