5.0.0_beta1: use PATH in execXX()

Hi Ian,

I want automount to use PATH when it tries to run e.g. "mount", because I want it to work regardless where my mount binary is (/bin or /usr/bin or...). I do have different system with different paths to some binaries, and it is pain in the ass - I have no way to explain to automount binary that it needs to look in another directory.

I am trying to make automount using 'short' names it by passing variables to configure:

MOUNT="mount" \
UMOUNT="umount" \
E2FSCK="fsck.ext2" \
E3FSCK="fsck.ext3" \
./configure ............

I think it's reasonably safe since automount is started by root and root is expected to set PATH sanely.

And it still doesn't work, because you are using execv(), not execvp().

This patch replaces execv() with execvp().

It should change nothing for 'normally' configured automount since it passes fully qualified names ("/bin/mount") to exec and PATH is not used in this case.

Please consider applying.
--
vda

diff -d -urpN autofs-5.0.0_beta1-stderr/daemon/spawn.c autofs-5.0.0_beta1-PATH/daemon/spawn.c
@@ -291,8 +291,12 @@ static int do_spawn(logger *log, int use
 		dup2(pipefd[1], STDERR_FILENO);
 		close(pipefd[1]);
 
-		execv(prog, (char *const *) argv);
-		_exit(255);	/* execv() failed */
+		/* Why execv_p_? Normally argv[0] has fully qualified path
+		 * and it doesn't matter, but it can be overridden
+		 * at build time to e.g. simple "mount".
+		 * Clearly, user wants to use PATH in this case. */
+		execvp(prog, (char *const *) argv);
+		_exit(255);	/* exec() failed */
 	} else {
 		close(pipefd[1]);
 

diff -d -urpN autofs-5.0.0_beta1-stderr/modules/lookup_program.c autofs-5.0.0_beta1-PATH/modules/lookup_program.c
@@ -171,8 +171,12 @@ int lookup_mount(struct autofs_point *ap
 		dup2(epipefd[1], STDERR_FILENO);
 		close(pipefd[1]);
 		close(epipefd[1]);
-		execl(ctxt->mapname, ctxt->mapname, name, NULL);
-		_exit(255);	/* execl() failed */
+		/* Why execl_p_? Normally argv[0] has fully qualified path
+		 * and it doesn't matter, but it can be overridden
+		 * at build time to e.g. simple "mount".
+		 * Clearly, user wants to use PATH in this case. */
+		execlp(ctxt->mapname, ctxt->mapname, name, NULL);
+		_exit(255);	/* exec() failed */
 	}
 	close(pipefd[1]);
 	close(epipefd[1]);

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Yes, people have asked for this fairly often.
I've resisted so far but perhaps I'm just wrong to do so. I'll have a look at this and think about it for a little while.

I still can't agree that using $PATH to locate executable maps is OK. If a system uses executable maps then I think the location of them should be specified in full.

Ian

--snip--

Well, in the development of autofs we started with file maps, and when executable maps were implemented it was natural to seem them as an evolution of file maps, i.e. properly found in /etc via a full path name. (/etc hasn't had generic executable content, like /etc/fsck, since 4.2BSD I believe). However, the requester has given a plausible scenario, the same master map used on multiple distros with different preferred homes for locally hacked executable files. Here at UCLA-Mathnet we had (in the past, thankfully) exactly this situation: Solaris, Irix, Ultrix and Linux at the same time and the same master map on all of them, although we stuck with the explicit path names in /etc. (I think we may have had tweaks per OS, actually, which occasionally got overwritten when some bozo installed the master map "everwhere".)

My feeling is that programs should allow the sysop maximum flexibility for possibly unique situations, absent a real operational need for the more restrictive solution. In other words, UNIX is supposed to let you shoot yourself in the foot. So I support using execvp to exec executable maps, even though I definitely won't be taking advantage of the feature.

James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [email protected] http://www.math.ucla.edu/~jimc (q.v. for PGP key)