Date: Sat, 26 Jan 2019 13:18:03 +0000 From: Edward Napierala <trasz@freebsd.org> To: Devin Teske <dteske@freebsd.org> Cc: rgrimes@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r343440 - head/bin/sh Message-ID: <20190126131803.GA28061@v2> In-Reply-To: <6DD219EC-C898-499E-BF58-AB653A7114DB@FreeBSD.org> References: <201901251709.x0PH9Rc4094379@repo.freebsd.org> <201901251957.x0PJvdTL089917@pdx.rh.CN85.dnsmgr.net> <CAFLM3-oSafSxcWSJPEXQ8szLEq5N593fr=sEsup6A2%2BP_VXrgQ@mail.gmail.com> <D7EEA6BA-EAA6-4A84-A7C4-904999B0E581@FreeBSD.org> <20190125082851.GA26199@v2> <1F038D39-8869-4220-A274-F6307A4264E2@FreeBSD.org> <20190125091334.GA26545@v2> <6DD219EC-C898-499E-BF58-AB653A7114DB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 0125T1647, Devin Teske wrote: > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala <trasz@freebsd.org> wrote: > > > > On 0125T1530, Devin Teske wrote: > >> > >> > >>> On Jan 25, 2019, at 12:28 AM, Edward Napierala <trasz@freebsd.org> wrote: > >>> > >>> On 0125T1441, Devin Teske wrote: > >>>> > >>>> > >>>>> On Jan 25, 2019, at 1:37 PM, Edward Napierala <trasz@freebsd.org> wrote: > >>>>> > >>>>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes > >>>>> <freebsd@pdx.rh.cn85.dnsmgr.net <mailto:freebsd@pdx.rh.cn85.dnsmgr.net>> napisał(a): > >>>>>> > >>>>>>> Author: trasz > >>>>>>> Date: Fri Jan 25 17:09:26 2019 > >>>>>>> New Revision: 343440 > >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/343440 > >>>>>>> > >>>>>>> Log: > >>>>>>> Comment out the default sh(1) aliases for root, introduced in r343416. > >>>>>>> The rest of this stuff is still to be discussed, but I think at this > >>>>>>> point we have the agreement that the aliases should go. > >>>>>>> > >>>>>>> MFC after: 2 weeks > >>>>>>> Sponsored by: DARPA, AFRL > >>>>>> > >>>>>> Please just revert this and the prior commit out, and when > >>>>>> the path forward is clear commit it. I would not want any of this > >>>>>> merged to 12/ or 11/ until the time that it is all settled. > >>>>> > >>>>> Oops, my bad - neither this nor the previous commit is supposed > >>>>> to be MFC-ed; the "2 weeks" above comes from my default Subversion > >>>>> config. > >>>>> > >>>>> Regarding the backoff - just a few hours ago you said you don't have > >>>>> any problem with this, except for aliases and the default ENV. The > >>>>> aliases problem has been addressed, and you hadn't yet responded > >>>>> to my explanations regarding the ENV. Another committer asked for > >>>>> backoff, because "sh is not an interactive shell", while in fact sh(1) > >>>>> is FreeBSD's default interactive shell except for root. Finally, there's > >>>>> one person who asked for revert, but without giving any reasons > >>>>> whatsoever. > >>>>> > >>>>> So far nobody had proposed any scenario where this would break > >>>>> anything, or even affect existing users. It seems like a typical bikeshed > >>>>> situation. > >>>> > >>>> It is not clear to me after reading r343416 and D18872 what this change is trying to solve. > >>> > >>> The idea is to make it easy to replace the default root shell - which > >>> many people consider broken, due to not supporting basic shell syntax - with > >>> something that actually works. > >> > >> How exactly does changing PS1 or adding 6 aliases fix the "basic shell syntax" which you claim to be unsupported? > >> > >> If the number of aliases added to a shell are a measure of its brokenness, then bash must be hella broken (I have 43 aliases in my bash_profile). > > > > The aliases are gone. > > Fair enough, albeit the topic was r343416 and D18872. > > > > Human-friendly PS1 is considered a standard feature > > nowadays. > > I fail to see how ''$ " is unfriendly. How many people you know use a plain '$' as a shell prompt, because they like it that way? > In fact, I am a bit amiss how you don't see "\u@\h:\w \\$ " as being unfriendly to TCL/Expect. > > While it's certainly possible to use "expect -re" and formulate around it, the change itself would break existing scripts. > > > > > But the way it fixes things is that it makes it easy to replace > > csh with a shell which actually groks shell syntax and is reasonably useful > > out of the box, > > This sounds like you are claiming csh is broken. > > I see where you may be coming from: > > + /bin/sh supports a syntax > + bash supports nearly all of /bin/sh > + zsh supports nearly all of /bin/sh > > So [t]csh must seem broken to you because it doesn't fall inline. > > Being different doesn't mean you are broken. As I have stated previously, I know lots of people that would and do set their login shell to tcsh. > > I personally have both a .tcshrc and a .bash_profile because I use both. I would never consider csh broken because it doesn't "grok shell syntax" -- it in-fact groks its own shell syntax just fine and dandy. I know people who use tcsh, too, but they are a minority of all users. However, this change doesn't do anything for them. > > with ~/.shrc you can customize etc. > > As can ~/.profile But ~/.profile won't work for aliases or the prompt; it's only run for login shells. And our sh(1) doesn't source ~/.shrc by itself, which is confusing to people coming from other systems. > > Think of it as a POLA, > > but horizontally, for folks coming from other systems, instead of the usual > > one. > > POLA can affect multiple people at the same time. > > Someone may be astonished that something is different when coming from anther community, but what if addressing this difference causes a POLA violation for long-standing users. That's true, but I don't think this change would violate POLA for the them. If they don't use sh, they are not affected. If they do, they already have their own config files, and so they are not affected either. > >> Also, the perhaps anecdotal consideration of brokenness is nearly laughable -- these can largely be lumped into one of three categories: > >> > >> a. Considered broken because it doesn't support bashisms > >> b. Considered broken because lack of syntactical knowledge > >> c. Considered broken because (no reason given) > > > > It's broken because it doesn't accept what people call the shell syntax. > > people from Linux? > people you know? > people in articles? > people on twitter? > > I don't have this experience. Users coming from Linux and/or OSX, which I believe are the majority of new users. > > Sure, some folks do realize there used to be something called 'csh', > > and people kept using it even into the nineties. > > That's one perspective. > > I started using tcsh in 2007. > I keep using it today. > I even use it on my Mac. > I also use it on Linux. > I continue to grow my ~/.tcsh file (currently at 410 lines) > > When I use tcsh, I appreciate it for the features that do not exist in any other shell ("repeat N cmd", "|&", etc.) Which is fine. I'm not advocating removing tcsh(1) from base. I'm not even trying to change the default root shell. The change we're discussing does not affect tcsh(1) at all - it only makes it easier for novices to switch to sh(1). > > But most users aren't > > actually that much into computing history; they expect the system to just > > work like they expect. > > > > You can ignore history, but it doesn't change the fact that we still maintain it. > > https://svnweb.freebsd.org/base/head/contrib/tcsh/?view=log <https://svnweb.freebsd.org/base/head/contrib/tcsh/?view=log>; > > I'm not into neologisms, but that doesn't mean new things don't stop being created. > > Is the end-goal to make sure that FreeBSD only has shells that are compatible with Linux ones? > > What about the very important matter of offering choice? > > I will digress because this is no longer about .shrc anymore and we should strive to stay on topic. Agreed. > >> Other languages might fit that description as well, and so we should take this anecdote of "many people consider broken" with a grain of salt. > >> > >> I personally have written more than 50,000 lines of shell for the FreeBSD base OS -- all utilizing /bin/sh > > > > And that's one of the reasons why I really apprieciate your response. > > Why thank you. > > I'll give an honest data point that I feel may be illuminating: > > While I consider myself to be proficient in bourne shell (actively rejecting bash, zsh, or other similar shell syntax), I have long been envious of [t]csh's syntax which allows for far fewer lines of code to achieve the same thing. > > Now, I will be the first to admit that csh has its warts (for example, try to throw away stdout but keep stderr through a series of redirects -- this is perhaps the only thing that /bin/sh makes easier than [t]csh), but it is ultimately a shining star for anyone that wants to script their system in a more friendly manner. > > CSH scripts that I have maintained, developed, and had shared with me over the past 15 years have always evoked a sense of respect, consternation, amazement, and humility from me. > > The difference, however, between /bin/sh and [t]csh is more like the differences between perl 5 and perl 6. They are wholly incompatible with each other and (csh being like perl 6) has features that really kick ass (think "grammars" if you're familiar with some of the things that make Perl 6 unique compared to Perl 5). That makes sense - csh(1) was created quite a bit later than sh(1), and since its authors went with a different syntax, they must had a good reason to do so. But my point is - even if csh(1)'s syntax is superior, it didn't catch on. Nowadays the word 'shell' is mostly synonymous with 'Bourne-compatible shell'. > >>>> PS1 should have a reasonable default. If that default is not reasonable, then we should change the C code. > >>>> > >>>> Maybe I see things differently, but I'd rather see PS1 default change so no profile/shrc change is necessary. > >>> > >>> Thank you, that's actually a valid argument. I believe that's also what > >>> bash does. It would be more intrusive, though, and I kind of don't like > >>> the idea of hardcoding things that can easily be dealt with with in a more > >>> "high-level" way. > >>> > >>>> I prefer that sh, in its default configuration, not attempt to read $HOME/.shrc, for security reasons. > >>> > >>> Can you elaborate? It already reads $HOME/.profile; how is $HOME/.shrc > >>> different? > >> > >> If you read "The Cuckoo's Egg" by Clifford Stoll, you'll understand the importance of "one place to exploit versus two." > >> > >> (situation) > >> > >> Say you've been running FreeBSD for 20 years (it turned 25 years old last year, so this is not only possible, but plausible). > >> You know all the areas of interest where an attacker could inject code. > >> You take care to lock down each one. > >> But come to your surprise ... > >> > >> (hypothetical) > >> > >> 6 months after you upgraded from 11.2 to the latest 12.x, you find that you didn't take into account that $HOME/.profile (which you perhaps locked down with a "chflags" command) now branches out to a new file which you've never taken steps to lock down, keep an eye on, or audit (e.g., by using DTrace remote-logging, tripwire, or other means). You only found out 6 months after the upgrade because someone exploited it. At that point, the security event has already occurred. > >> > >> When I worked at "the banks" shit like this was always on our radar. Changes like this were often cited for the reason why one bank moved to BoKs for security. > > > > The change we're discussing doesn't affect upgrades at all - it's only > > for new installs. > > mergemaster, iirc, will merge in changes to etc files after an upgrade. > So this would effect anybody that goes through an upgrade and performs mergemaster. See the sibling mail. > > And it only affects root, for whom the answer to > > 'where an attacker could inject code' question is 'literally everywhere, > > including the firmware'. > > This is not true in many situations. One being in a capsicum env or one where the MAC (TrustedBSD Mandatory Access Control) framework sets limitations. With Capsicum you're not able to execute a shell at all. With MAC... it depends on the policy, but then we don't ship with MAC configured. > > And it doesn't affect root by default, you > > need to change their shell from csh(1) to sh(1). > > By your own commit messages admission, this is for the toor account, so it does affect a user (and as you were keen to point out, users with the default shell). True, but the toor account is locked out by default. [..] > >>>> If you wanted your new shiny default PS1 to actually have an effect in all modes (including privileged mode, where you probably want it), you would have put it in /etc/profile and not in a file that is wholly ignored by some modes (e.g., privileged mode). > >>>> So the solution is not even the right one for the desired result. > >>> > >>> I would, if only it didn't break zsh, and perhaps others. The > >>> problem here is that zsh uses different syntax for PS1, _and_ > >>> it also parses /etc/profile. > >>> > >>> And no, I don't care at all about privileged mode, I can't imagine > >>> a situation when using it would be a good idea. > >>> > >> > >> Rampant hand-waving. > >> > >> OK, that still leaves the fact that a non-static PS1 fucks with TCL/Expect programmers. > > > > True, that's a valid argument. Question is, is the number of FreeBSD > > systems (others already use more complicated PS1 by default) to be deployed > > (the change doesn't affect existing installations) with root shell changed > > to sh(1) (the change doesn't affect situations when sh(1) is not your login > > shell) that have to interface with Expect scripts that can't handle more > > complicated prompts, large enough to actually care? > > We started talking about toor because it has no shell specified in /etc/passwd and therefore uses the default shell (/bin/sh). > > Also, upgrade/mergemaster to me seems like it would affect existing installations. > > Now that I think about it, people using TCL/Expect against the root account would be talking to csh and probably not be effected. > > Is it too late to change my vote? Not at all - from my understanding _the_ contentious part were the aliases, which are now gone. Although I don't really consider it 'voting' - if the commit can actually break some reasonable use-case, it'll get reverted even if there's just a single person reporting it. > Let me sit on this for a few hours. The TCL/Expect argument may be neutralized because -- as you correctly state -- is probably a minority of situations. However, I am still concerned about upgrade/mergemaster. > > Maybe a simple UPDATING entry can be used to address the former concern about corporate secteams needing to be kept informed of this nominal [potential] change. It could work, although UPDATING is for... well, updates, and this is for new installs.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190126131803.GA28061>