Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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 Rosjatfon: +49 351 8107224mail: ros...@ghweb.de 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
Re: doas behaviour in recent snapshot [was Re: 6.4 doas gives "command not found" if no #!/bin/sh up top]
Known bug. Use full path until it's fixed.
doas behaviour in recent snapshot [was Re: 6.4 doas gives "command not found" if no #!/bin/sh up top]
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
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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). > > >
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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.
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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). >
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
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).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
>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.
6.4 doas gives "command not found" if no #!/bin/sh up top
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
