Monday, October 29, 2018

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

No comments:

Post a Comment