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