On Čt, 2015-10-22 at 14:22 +0000, Byrnes, Robert wrote:
The crond -P option seems buggy. The manpage says that it causes the
PATH [used for commands] to be "inherited from the environment" [of crond].
However, that doesn't happen: it actually causes the PATH to be *omitted* from the
environment, because the environment for each command is initialized to be empty, and
nothing ever copies the PATH from crond's environment into the command's
environment.
This is hard to observe, for several reasons:
- If PAM is enabled, then PAM sets the PATH.
- If the shell is bash, then bash sets the PATH to its own default if it encounters PATH
unset when it starts.
I think something like this fixes it:
--- a/src/entry.c
+++ b/src/entry.c
@@ -345,8 +345,18 @@ entry *load_entry(FILE * file, void (*error_func) (), struct passwd
*pw,
}
#ifndef LOGIN_CAP
/* If login.conf is in used we will get the default PATH later. */
- if (ChangePath && !env_get("PATH", e->envp)) {
- if (glue_strings(envstr, sizeof envstr, "PATH", _PATH_DEFPATH,
'=')) {
+ if (!env_get("PATH", e->envp)) {
+ char *defpath;
+
+ if (ChangePath)
+ defpath = _PATH_DEFPATH;
+ else {
+ defpath = getenv("PATH");
+ if (defpath == NULL)
+ defpath = _PATH_DEFPATH;
+ }
+
+ if (glue_strings(envstr, sizeof envstr, "PATH", defpath,
'=')) {
if ((tenvp = env_set(e->envp, envstr)) == NULL) {
ecode = e_memory;
goto eof;
Thoughts?
Yes, this makes sense, I'll commit that. Thanks for the patch.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)