Date: Sat, 26 Jan 2019 09:28:04 -0700 From: Ian Lepore <ian@freebsd.org> To: Edward Napierala <trasz@freebsd.org>, 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: <311b99b491846d635076d2feb58cf568c15f4154.camel@freebsd.org> In-Reply-To: <20190126131803.GA28061@v2> 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> <20190126131803.GA28061@v2>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2019-01-26 at 13:18 +0000, Edward Napierala wrote: > 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. > No, it's not just the aliases. The part that angers me the most is the changing of PS1. I still haven't seen anything that justifies any of these changes other than your opinion that you like your changes better than what was there before. -- Ian > > 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?311b99b491846d635076d2feb58cf568c15f4154.camel>