6.4 doas gives "command not found" if no #!/bin/sh up top

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

6.4 doas gives "command not found" if no #!/bin/sh up top

Derek Sivers-2
Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed.

I finally solved it, but just posting here in case anyone has this problem.

I had a few little shell scripts in /usr/local/sbin/ - intended to be run
by doas : one-liners like bioctl mounting a USB stick or whatever.

After upgrading to OpenBSD 6.4, all of them returned a "command not found"
error.  I tried moving them to different paths in $PATH, but no luck.
Yet they'd work if I was root - just not via doas.

Adding a "#!/bin/sh" at the top of the scripts made them all work again.

Just FYI.

- Derek

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Thomas Frohwein-2


>Adding a "#!/bin/sh" at the top of the scripts made them all work
>again.

Sounds like now the behavior is as it should be. If you really need the old behavior back you could try running the scripts with the dot command.

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Ted Unangst-6
In reply to this post by Derek Sivers-2
Derek wrote:

> Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed.
>
> I finally solved it, but just posting here in case anyone has this problem.
>
> I had a few little shell scripts in /usr/local/sbin/ - intended to be run
> by doas : one-liners like bioctl mounting a USB stick or whatever.
>
> After upgrading to OpenBSD 6.4, all of them returned a "command not found"
> error.  I tried moving them to different paths in $PATH, but no luck.
> Yet they'd work if I was root - just not via doas.
>
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Ted Unangst-6
Ted Unangst wrote:

> Derek wrote:
> > Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed.
> >
> > I finally solved it, but just posting here in case anyone has this problem.
> >
> > I had a few little shell scripts in /usr/local/sbin/ - intended to be run
> > by doas : one-liners like bioctl mounting a USB stick or whatever.
> >
> > After upgrading to OpenBSD 6.4, all of them returned a "command not found"
> > error.  I tried moving them to different paths in $PATH, but no luck.
> > Yet they'd work if I was root - just not via doas.
> >
> > 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.


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

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Ted Unangst-6
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).

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

tomr


On 10/22/18 9:48 AM, Ted Unangst wrote:

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

I'm a bit confused here. I have some cwm keybindings that `doas rcctl`
things, which now aren't working as they used to - which isn't
necessarily a problem - but I'm surprised at the behaviour below:

# this doesn't work anymore..
$ doas rcctl
doas: rcctl: command not found

# these all still work..
$ doas sh -c rcctl
usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
        rcctl [-df] check|reload|restart|stop|start daemon ...
        rcctl disable|enable|order [daemon ...]
        rcctl ls all|failed|off|on|started|stopped
# tried with ktrace to see where it was getting stuck, but it worked..
$ doas ktrace rcctl
usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
        rcctl [-df] check|reload|restart|stop|start daemon ...
        rcctl disable|enable|order [daemon ...]
        rcctl ls all|failed|off|on|started|stopped
$ doas /usr/sbin/rcctl
usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
        rcctl [-df] check|reload|restart|stop|start daemon ...
        rcctl disable|enable|order [daemon ...]
        rcctl ls all|failed|off|on|started|stopped

# /usr/sbin is in my path
$ echo $PATH
/home/tomr/perl5/bin:/home/tomr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games

# other commands from /usr/sbin still work
$ which vmctl
/usr/sbin/vmctl
$ doas vmctl
usage:  vmctl [-v] command [arg ...]
        vmctl console id
        vmctl create "path" [-b base] [-i disk] [-s size]
        vmctl load "path"
        vmctl log [verbose|brief]
        vmctl reload
        vmctl reset [all|vms|switches]
        vmctl show [id]
        vmctl start "name" [-Lc] [-b image] [-r image] [-m size]
                [-n switch] [-i count] [-d disk]* [-t name]
        vmctl status [id]
        vmctl stop [id|-a] [-fw]
        vmctl pause id
        vmctl unpause id
        vmctl send id
        vmctl receive id
$

So, what's special about rcctl?

t

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

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Ted Unangst-6
tomr wrote:
> I'm a bit confused here. I have some cwm keybindings that `doas rcctl`
> things, which now aren't working as they used to - which isn't
> necessarily a problem - but I'm surprised at the behaviour below:
>
> # this doesn't work anymore..
> $ doas rcctl
> doas: rcctl: command not found

are you using a snapshot? there's something broken, but 6.4 should work.

Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Theo de Raadt-2
In reply to this post by tomr
Tom you have changed a conversation about one problem into a
conversation about a different problem

It is confusing.

Please don't do that.

> On 10/22/18 9:48 AM, Ted Unangst wrote:
> > 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.
>
> I'm a bit confused here. I have some cwm keybindings that `doas rcctl`
> things, which now aren't working as they used to - which isn't
> necessarily a problem - but I'm surprised at the behaviour below:
>
> # this doesn't work anymore..
> $ doas rcctl
> doas: rcctl: command not found
>
> # these all still work..
> $ doas sh -c rcctl
> usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
>         rcctl [-df] check|reload|restart|stop|start daemon ...
>         rcctl disable|enable|order [daemon ...]
>         rcctl ls all|failed|off|on|started|stopped
> # tried with ktrace to see where it was getting stuck, but it worked..
> $ doas ktrace rcctl
> usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
>         rcctl [-df] check|reload|restart|stop|start daemon ...
>         rcctl disable|enable|order [daemon ...]
>         rcctl ls all|failed|off|on|started|stopped
> $ doas /usr/sbin/rcctl
> usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
>         rcctl [-df] check|reload|restart|stop|start daemon ...
>         rcctl disable|enable|order [daemon ...]
>         rcctl ls all|failed|off|on|started|stopped
>
> # /usr/sbin is in my path
> $ echo $PATH
> /home/tomr/perl5/bin:/home/tomr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games
>
> # other commands from /usr/sbin still work
> $ which vmctl
> /usr/sbin/vmctl
> $ doas vmctl
> usage:  vmctl [-v] command [arg ...]
>         vmctl console id
>         vmctl create "path" [-b base] [-i disk] [-s size]
>         vmctl load "path"
>         vmctl log [verbose|brief]
>         vmctl reload
>         vmctl reset [all|vms|switches]
>         vmctl show [id]
>         vmctl start "name" [-Lc] [-b image] [-r image] [-m size]
>                 [-n switch] [-i count] [-d disk]* [-t name]
>         vmctl status [id]
>         vmctl stop [id|-a] [-fw]
>         vmctl pause id
>         vmctl unpause id
>         vmctl send id
>         vmctl receive id
> $
>
> So, what's special about rcctl?
>
> t
>
> >
> >>
> >>
> >>>
> >>> 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).
> >
>

Reply | Threaded
Open this post in threaded view
|

doas behaviour in recent snapshot [was Re: 6.4 doas gives "command not found" if no #!/bin/sh up top]

tomr
In reply to this post by Ted Unangst-6


On 10/30/18 10:11 AM, Ted Unangst wrote:

> tomr wrote:
>> I'm a bit confused here. I have some cwm keybindings that `doas rcctl`
>> things, which now aren't working as they used to - which isn't
>> necessarily a problem - but I'm surprised at the behaviour below:
>>
>> # this doesn't work anymore..
>> $ doas rcctl
>> doas: rcctl: command not found
>
> are you using a snapshot? there's something broken, but 6.4 should work.
>

Quite right. I spun up 6.4-RELEASE in a vm and it works as expected.

I'm seeing the issue on this snapshot:
OpenBSD 6.4-current (GENERIC.MP) #408: Sun Oct 28 23:10:11 MDT 2018

Apologies for piggybacking an older thread and assuming this was the
same issue!

t

Reply | Threaded
Open this post in threaded view
|

Re: doas behaviour in recent snapshot [was Re: 6.4 doas gives "command not found" if no #!/bin/sh up top]

jungle Boogie
Known bug. Use full path until it's fixed.
Reply | Threaded
Open this post in threaded view
|

Re: 6.4 doas gives "command not found" if no #!/bin/sh up top

Markus Rosjat
In reply to this post by Ted Unangst-6
Hi all,

>>> Derek wrote:
>>>> Adding a "#!/bin/sh" at the top of the scripts made them all work again.

it seems this is also happening with python scripts even you have
shebang. To solve this you should change lines like

#!/usr/local/bin/python

to

#!/usr/bin/env python

after this change was made doas worked as expected with the script

regards

--
Markus Rosjat    fon: +49 351 8107224    mail: [hidden email]

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT