<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 7, 2023 at 1:43 PM Chet Ramey <<a href="mailto:chet.ramey@case.edu">chet.ramey@case.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/7/23 3:29 PM, enh wrote:<br>
<br>
> cd is a weird one. The v7 Bourne shell exited the shell if the directory<br>
> argument didn't exist, and that didn't change until SVR4.2,<br>
> <br>
> <br>
> and people complain unix isn't user-friendly... :-)<br>
<br>
Ha. Sometimes they write books on the subject.<br>
<br>
> > I know there's the "this<br>
> > may syntax error and exit the shell" distinction but don't ask me<br>
> how set or<br>
> > true are supposed to do that.<br>
> <br>
> set exits the shell on an invalid option and was special in the Bourne<br>
> shell; true isn't a special builtin.<br>
> <br>
> (I _think_ they added set here because set -u can<br>
> > cause a shell error later? Maybe? But then why unset?<br>
> <br>
> Well, unset didn't exist in the 7th edition shell, but it's special<br>
> in the SVR4 shell. It can only fail if asked to unset a readonly<br>
> variable or one of the shell's non-unsettable variables. It takes no<br>
> options, does no argument checking for invalid identifiers, and unsetting<br>
> a variable that's not set isn't an error, but when asked to unset a<br>
> variable the shell says you can't, the shell exits.<br>
> <br>
> I think POSIX made unset a special builtin because the SVR4 sh did and<br>
> so it would be found in the command search before a function. That gets<br>
> important when you're trying to write a secure script,<br>
> <br>
> <br>
> did the v7 bourne shell just not know whether it was interactive or not? <br>
<br>
Of course it did.<br>
<br>
> (because, yeah, this kind of thing makes a lot more sense as an early `set <br>
> -e`. but i can't imagine using this interactively!)<br>
<br>
The 7th edition shell doesn't exit if it's interactive and a special<br>
builtin fails, that wouldn't make any sense at all. Interactive shells<br>
just abort the command and jump back to the main command loop. It's the<br>
same in POSIX.<br>
<br>
The 7th edition shell did have `set -e'; Bourne put it in for `make'.<br>
<br>
> Yeah, there's a ways to go.<br>
> <br>
> <a href="https://lists.gnu.org/archive/html/help-bash/2023-06/msg00117.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/help-bash/2023-06/msg00117.html</a><br>
> <<a href="https://lists.gnu.org/archive/html/help-bash/2023-06/msg00117.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/help-bash/2023-06/msg00117.html</a>><br>
> <br>
> They mess up the simple stuff.<br>
> <br>
> <br>
> define "mess up"... <br>
<br>
Maybe "mess up" was too strong. I think it's rude to send a fatal signal if<br>
you have the function. Either don't provide it or make it return -1/ENOSYS.<br>
Android is by no means the only place this is a problem; it happens with<br>
docker all the time:<br>
<br>
<a href="https://lists.gnu.org/archive/html/bug-bash/2022-03/msg00010.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/bug-bash/2022-03/msg00010.html</a></blockquote><div><br></div><div>yeah, if it's any consolation we argued about this choice a lot. (which is probably also why the choice exists in the first place!)</div><div><br></div><div>iirc we even _tried_ -1/ENOSYS to test the predictions that (a) most c programmers don't check for failures (b) even those that do don't log enough to be able to debug these problems and (c) even in cases where errors are checked and logged, the ability of folks -- including _end users_ -- to triage such problems is limited. i'm not a _fan_ of SIGSYS, but i do still think it was the lesser of the available evils. (but of course it's the folks who _do_ check for failures who're most likely to disagree; in an ideal world, it would have been good for "sophisticated" code to be able to opt out. though that kind of thing always falls apart at library boundaries; not all code linked together is of the same quality.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> Android deliberately has strict seccomp filters for <br>
> apps, and the syscalls mentioned in that post are on the "no" list. Android <br>
> gives each _app_ a different uid, so there's typically nothing useful you <br>
> can do here anyway. (things are a bit different if you're actually part of <br>
> the OS, but bash being GPL makes that unlikely :-( )<br>
<br>
Sure. But if you have the function, bash assumes it works as documented in<br>
the rest of the Linux world.<br></blockquote><div><br></div><div>and so it does, if you're not an app.</div><div><br></div><div>the tricky case here has always been the conflict between the folks who want to check at build time versus those who want to check at runtime ... if we hide things in the headers, people complain "i wasn't going to call it unless i know i can anyway". (plus in addition to the general rule that "most configure scripts don't handle cross-compilation correctly", you'd be surprised how many screw up the simple "is this function available?" test --- they don't compile a small program that #includes the right header and tries to call the function; they grep the header or nm the library or whatever.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> (yes, i agree that it's mildly unfortunate that there's no special case for <br>
> "i don't actually want to change anything", which i think is the case <br>
> they're talking about in that post, and i've wondered about adding that to <br>
> libc once or twice, but my feeling is that it wouldn't be particularly <br>
> useful in practice because _that_ kind of code probably needs a rethink <br>
> anyway when porting to Android.)<br>
<br>
I just added code to bash that doesn't try to call setresuid/setresgid if<br>
nothing is actually changing, which will save a couple calls everywhere.<br>
But killing the process is rude.<br></blockquote><div><br></div><div>you're talking to the guy who added the equivalent of `if (fp == NULL) abort_with_message("you can't pass a null FILE*");` to every stdio function because too many developers don't check fopen() succeeded, and think libc is broken if fgets() dereferences a null pointer. killing a process with a "you called syscall %d and you're not allowed to" message is pretty much exactly what you'd expect from me :-) (i only wish i could cheaply replace the %d with a %s ... most people seem to struggle translating the syscall numbers correctly [grepping their x86-64 host's headers seems to be a popular choice], but i don't see those bugs often enough to warrant a giant table of error-message-only strings.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> but, yeah, "security" and "self-hosting" aren't exactly friends ... the 1% <br>
> bad guys being the reason we can't have nice things, as usual. (executing <br>
> code off a writable filesystem being frowned upon.)<br>
<br>
Oh, I get it.<br>
<br>
<br>
> Thorsten would be happy for android to keep using mksh, I'm sure.<br>
> <br>
> <br>
> (and i'm going to have a lot of fun dealing with compatibility issues <br>
> if/when we move /bin/sh over...)<br>
<br>
You know you will, it's best to start looking forward to it now.<br></blockquote><div><br></div><div>_especially_ when rob's listening, i'm careful to not commit to more than giving it a go :-)</div><div><br></div><div>it might not seem like it from the outsiders (because you only see the stuff that _does_ break), but i'm sure as the maintainer of something old and widely-used you're well aware that "not breaking everyone's stuff [even when it's terrible]" is a large part of the job. (and, ironically, i've come to believe that breaking it _loudly and clearly_ when you have to [for security, usually] is the least worst option.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Chet<br>
-- <br>
``The lyf so short, the craft so long to lerne.'' - Chaucer<br>
``Ars longa, vita brevis'' - Hippocrates<br>
Chet Ramey, UTech, CWRU <a href="mailto:chet@case.edu" target="_blank">chet@case.edu</a> <a href="http://tiswww.cwru.edu/~chet/" rel="noreferrer" target="_blank">http://tiswww.cwru.edu/~chet/</a><br>
<br>
</blockquote></div></div>