Follow-up Comment #6, bug #28934 (project hurd): > > The reason argv[0] is expanded is because it is passed as an argument > > to the interpreter, otherwise the interpreter can't find it. > > Unless it is a relative path, of course.
I did mean any path, relative or not. What's important is that e.g. `ps' expands to `/bin/ps' instead of non-existent file `ps'. > >> Actually I don't think the exec server needs to know what exec*() variant > >> has been called, since the call itself will have called execve() with > >> the full path by looking at PATH if needed (see glibc's posix/execvpe.c, > >> the beginning of the do-while() loop around line 140). > > > > As explained above, the full path isn't sent to the exec server. > > But since all of exec() go are wrappers around execve(), and execve() > opens the path passed to it without looking at $PATH, and then passes > it to the exec server as is, we can assume the path in argv[0] is > the same one that was used to open the port, and that it's either a > relative or an absolute path, and we don't need to look at $PATH at > all. (That is for the exec() cases, I don't know for other things that > use _hurd_exec()). Normally, argv[0] is the same as the file argument to exec*(), so an execvp("foo") will still have argv[0] = "foo", even if it results in a execve("/bin/foo"). But note that this is just convention as argv[0] can be an arbitrary string... > > I now think a better solution is to change the exec server to look in > > the current directory for the file. > > The question is whether this is secure, and I'd say `yes' simply > > because the path reconstruction seems pretty haphazardous as it is. > > While the exec server does do some tests on the file with io_identity, > > it is pretty easy for a file to fake this information, and I suspect this > > is the reason the exec server only tries to reconstruct the path if the > > EXEC_SECURE flag is off. To be on the safe side the current directory > > should be checked after $PATH. > > I'm not really convinced about looking in the current directory, > although if we do, doing it after looking at $PATH sounds reasonable. I agree that this is an unsatisfying solution, but I recommend that you do this first before you start with a more extravagant solution. Then we'll have fixed the problem at hand even if the better solution gets stalled. > > A final solution might be to change the exec protocol so that exec*() > > can pass on the files path, which seems much more robust. Or possibly > > do the checking for #!-scripts in glibc... But you don't have to worry > > about this, unless you want to of course. :-) > > Changing the exec server so that we can pass it the full path sounds > like the best option to me. What would be the best way to do it? Maybe > adding a new _hurd_exec_path(task, file, path, argv, envp) that avoids > looking at $PATH? Well, this is an extensive change. You'll need to add a path parameter to at least the following: _hurd_exec, file_exec, exec_exec, and change all callers. Giving them new names, e.g. _hurd_exec_path, might be a good idea to avoid incompatibilities, but eventually we'll want to deprecate the original versions. I don't know how this should be handled in general; you'll want to get a more authoritative answer from Thomas Schwinge, or possibly Olaf Buddenhagen or Samuel Thibault. But really, do the current directory lookup first. :-) Regards, Fredrik _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?28934> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/