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

[Gary Johnson]

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