Ted Unangst wrote:
> Ted Unangst wrote:
> > Derek wrote:
> > > Adding a "#!/bin/sh" at the top of the scripts made them all work again.
> >
> > i don't believe this is a change; that's how it should always work.
>
> sorry, this appears wrong. doas actually uses execvpe() from libc, which is
> supposed to do the sh interpretation thing, except now it doesn't work right.
> this is a behavior change.
sorry for the burst of email. i was a little out of touch about what was
happening. there were changes made, but they were not entirely expected or
planned.
old behavior: doas uses execvpe(), which as the man page notes, follows sh
behavior and will execute the command using the sh if it has the x bit but
lacks a magic header.
new behavior: some unveil() calls were added to doas which restricts access to
/bin/sh, meaning execvpe() no longer works as before.
as hinted in my original reply below, i kind of like this behavior. the change
to restrict commands to only those with valid headers was inadvertent, but the
outcome seems positive. we will probably stick with it.
so... the behavior changed, that's probably a bug, but we're going to call it
a feature. problem solved. :)
some documentation changes may be forthcoming to make everything clear.
thanks for finding and reporting this.
>
>
> >
> > execve() returns ENOEXEC if the file doesn't have the right magic header. sh
> > will attempt to interpret the file as a script after that error, but i don't
> > think doas should have such a fallback. it may not be a sh script, and then
> > weird and possibly bad things will happen (has happened before).
No comments:
Post a Comment