Hello, On Mon, Apr 18, 2011 at 04:55:55AM -0500, Jonathan Nieder wrote: > > Questions: > > * This ignores failure to nscd on platforms reporting it through > WIFEXITED(status) && WEXITSTATUS(status) == 127 but considers it an > error when it comes from the return value of posix_spawn. Which > behavior is intended? > > One possibility might be to return 0 for ENOENT (since it is an > expected error) and ignore normal exits with nonzero status > (because nscd can exit with status 1 if the daemon wasn't > running or 127 if it doesn't exist) but report other errors.
This could be a possibility. But it would still be inconsistent. When WIFEXITED(status) && WEXITSTATUS(status) == 127 any error may have occurred. There is IMO no robust way to find out what was the exec error when fork succeeded. Also nscd failures are not checked. There could be two options: * test if nscd exists and is executable * get rid of posix_spawn, replace by fork & exec abd report errors, except for ENOENT The second option is probably the best but is the most complex. (The current behavior seems to be "try to execute nscd, but do not care whether it is executed successfully, but if the trying to execute failed then report an error") > * Is it intended that "nscd" is passed as argv[1] rather than argv[0]? Yes, argv[1] is just a name and could be anything. argv[0] is the executable. > * Why not use the PATH (posix_spawnp) to discover where "nscd" is, to > allow the admin to install a copy to /usr/local/sbin/nscd? The goal is to get the system's nscd executed and avoid any mean from the user to execute another program (some of the shadow utils are or may be setuid root). One option could be to have it configurable (e.g. in /etc/login.defs or /etc/default/useradd) > * Is it safe to run nscd with an empty environment (in particular > without $PATH)? Is the environment scrubbing intended? This is intentional, as above, to avoid any interaction between the caller and nscd. If nscd has some need for a defined PATH, this is not documented. I guess it would fail at worse. My current intent is to replace the posix_spawn call, but do not intent to change the other points. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
