[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

[Emilio Pozuelo Monfort]

Follow-up Comment #5, 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.

> Also, ``./foo bar'' gets me `bar' in Linux not `./bar'. Are you sure 
> you got `./bar' in this case? 

Sorry I was wrong. I also get bar in that case.

>> 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()).

>> Another similar option is to prepend . to $PATH in that case (and then 
>> the exec server will prepend ./ to the file). 
> 
> This isn't a good idea either since the child process will end up with 
> a different $PATH as a side-effect. 

Oh right.

> 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.

> 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?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?28934>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/