Bug 711654

Summary: crontab PATH not properly expanded
Product: [Fedora] Fedora Reporter: JW <ohtmvyyn>
Component: cronieAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: mmaslano, pertusus, tmraz
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-04 11:36:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description JW 2011-06-08 04:43:46 UTC
Description of problem:
Although it is possible to have a PATH environment definition in a crontab other environment variables on the rhs are not expanded

Version-Release number of selected component (if applicable):
cronie-1.4.7-3

How reproducible:
Always

Steps to Reproduce:
1. create this C program (x.c) and save compiled result in ~/bin/x:
#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char **argv)
{
    execvp(argv[1], &argv[1]);
    fprintf(stderr, "Exec failed\n");
    exit(1);
}

2. create this crontab entry and wait for it to run:
      PATH=$HOME/bin
      * * * * * x /bin/pwd </dev/null

3. create this crontab entry and wait for it to run:
      PATH=~/bin
      * * * * * x /bin/pwd </dev/null

4. create this crontab entry and wait for it to run:
      PATH=$HOME/bin
      * * * * * /usr/bin/xargs x /bin/pwd </dev/null

5. create this crontab entry and wait for it to run:
      PATH=~/bin
      * * * * * /usr/bin/xargs x /bin/pwd </dev/null

6. create this crontab entry and wait for it to run:
      PATH=/home/users/<YOU>/bin
      * * * * * /usr/bin/xargs x  /bin/pwd </dev/null

Actual results:
2. fail: sh: /bin/sh: x: command not found
3. ok: /home/users/<YOU>
4. fail: /usr/bin/xargs: x: No such file or directory
5. fail: /usr/bin/xargs: x: No such file or directory
6. ok: /home/users/<YOU>

Expected results:
2. ok: /home/users/<YOU>
3. ok: /home/users/<YOU>
4. ok: /home/users/<YOU>
5. ok: /home/users/<YOU>
6. ok: /home/users/<YOU>

Additional info:
The problem is to do with expansion of either HOME or ~ and the use of execvp. While execvp duplicates the actions of the shell somewhat it does not substitute  for $HOME or ~. But crond executes crontab lines using "sh -c" which is why case 3 works, and case 2 fails (the actual PATH contains an unexpanded $HOME).

Users are mostly used to using constructs such as "PATH=$HOME/bin" which work because the shell expands the rhs and stores the expanded PATH setting. It can be difficult to see that the internal PATH contains an unexpanded variable because naive 'echo $PATH' will also expand any embedded unexpanded variable.

So to be consistent it would be best if crond expanded the rhs of a PATH setting so as to properly substitute for ~ and environment variables.  Because it certainly seems very weird for this to not happen.  It defies common sense. It contradicts all other known cases where a PATH can be set

Comment 1 Tomas Mraz 2011-06-08 07:02:21 UTC
This is really nontrivial. To fully emulate the shell expansion the shell would have to be called to expand the right hand side of the env assignment. Of course this expansion would have to run as the appropriate crontab user and with the environment same as it would be seen by the user session.

Having the cronie to do some trivial expansion on itself would mean that it would not be fully shell compatible anyway.

Comment 2 JW 2011-06-08 07:19:43 UTC
I beg to differ. This IS relatively trivial.  I've written similar code and it comes to now more than 200 lines of code (and I use braces on separate lines!).

> Having the cronie to do some trivial expansion on itself would mean that it
> would not be fully shell compatible anyway.

But wait - first you say it would be "nontrivial", now in almost the same breath you say "trivial".

And saying that "cronie" would somehow not be fully shell compatible is a nonsense.  We are only talking about the expansion of the rhs on a minor number of lines of a crontab - only the env lines and they are already treated separately from other lines.

In what way would cronie not be "fully shell compatible"? Please explain.

And I also suggest you read the code first.

Comment 3 Tomas Mraz 2011-06-08 07:31:13 UTC
Patches are of course welcome :)

Comment 4 Marcela Mašláňová 2014-09-04 11:36:13 UTC
No change in last three years. Closing.