Date: Fri, 25 Jan 2019 16:47:27 -0800 From: Devin Teske <dteske@FreeBSD.org> To: Edward Napierala <trasz@freebsd.org> Cc: Devin Teske <dteske@FreeBSD.org>, 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: <6DD219EC-C898-499E-BF58-AB653A7114DB@FreeBSD.org> In-Reply-To: <20190125091334.GA26545@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 25, 2019, at 1:13 AM, Edward Napierala <trasz@freebsd.org> = wrote: >=20 > On 0125T1530, Devin Teske wrote: >>=20 >>=20 >>> On Jan 25, 2019, at 12:28 AM, Edward Napierala <trasz@freebsd.org> = wrote: >>>=20 >>> On 0125T1441, Devin Teske wrote: >>>>=20 >>>>=20 >>>>> On Jan 25, 2019, at 1:37 PM, Edward Napierala <trasz@freebsd.org> = wrote: >>>>>=20 >>>>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes >>>>> <freebsd@pdx.rh.cn85.dnsmgr.net = <mailto:freebsd@pdx.rh.cn85.dnsmgr.net>> napisa=C5=82(a): >>>>>>=20 >>>>>>> Author: trasz >>>>>>> Date: Fri Jan 25 17:09:26 2019 >>>>>>> New Revision: 343440 >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/343440 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> MFC after: 2 weeks >>>>>>> Sponsored by: DARPA, AFRL >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> So far nobody had proposed any scenario where this would break >>>>> anything, or even affect existing users. It seems like a typical = bikeshed >>>>> situation. >>>>=20 >>>> It is not clear to me after reading r343416 and D18872 what this = change is trying to solve. >>>=20 >>> 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. >>=20 >> How exactly does changing PS1 or adding 6 aliases fix the "basic = shell syntax" which you claim to be unsupported? >>=20 >> 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). >=20 > 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. 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. > with ~/.shrc you can customize etc. As can ~/.profile > 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. >=20 >> Also, the perhaps anecdotal consideration of brokenness is nearly = laughable -- these can largely be lumped into one of three categories: >>=20 >> a. Considered broken because it doesn't support bashisms >> b. Considered broken because lack of syntactical knowledge >> c. Considered broken because (no reason given) >=20 > 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. > 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.) > But most users aren't > actually that much into computing history; they expect the system to = just > work like they expect. >=20 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=3Dlog = <https://svnweb.freebsd.org/base/head/contrib/tcsh/?view=3Dlog>; 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. >> 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. >>=20 >> I personally have written more than 50,000 lines of shell for the = FreeBSD base OS -- all utilizing /bin/sh >=20 > 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). >=20 >>>> PS1 should have a reasonable default. If that default is not = reasonable, then we should change the C code. >>>>=20 >>>> Maybe I see things differently, but I'd rather see PS1 default = change so no profile/shrc change is necessary. >>>=20 >>> 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. >>>=20 >>>> I prefer that sh, in its default configuration, not attempt to read = $HOME/.shrc, for security reasons. >>>=20 >>> Can you elaborate? It already reads $HOME/.profile; how is = $HOME/.shrc >>> different? >>=20 >> If you read "The Cuckoo's Egg" by Clifford Stoll, you'll understand = the importance of "one place to exploit versus two." >>=20 >> (situation) >>=20 >> 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 ... >>=20 >> (hypothetical) >>=20 >> 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. >>=20 >> 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. >=20 > 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. > 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. > 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). >=20 >>>> Further, it is documented that the contents of ENV may be ignored = in privileged mode, negating these changes. >>>=20 >>> True - so if someone finds the idea of having a suid shell useful - = from >>> what I undestand that's what the privileged mode boils down to - = this >>> change will be a no-op. I seriously hope nobody does, though. >>>=20 >>=20 >> =46rom the manual: >>=20 >> -p privileged >> Turn on privileged mode. This mode is enabled on startup = if >> either the effective user or group ID is not equal to the = real >> user or group ID. Turning this mode off sets the = effective user >> and group IDs to the real user and group IDs. When this = mode is >> enabled for interactive shells, the file = /etc/suid_profile is >> sourced instead of ~/.profile after /etc/profile is = sourced, and >> the contents of the ENV variable are ignored. >>=20 >> So as you can see, it's suid *or* sgid. >>=20 >> I can think of plenty of places where sgid is common. >=20 > Okay. I've never seen an sgid shell myself, but I believe you. = Still, > for that case the change we're discussing is a no-op. >=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> Rampant hand-waving. >>=20 >> OK, that still leaves the fact that a non-static PS1 fucks with = TCL/Expect programmers. >=20 > 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? 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. --=20 Devin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6DD219EC-C898-499E-BF58-AB653A7114DB>