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 at freebsd.org>
> > > wrote:
> > >
> > > On 0125T1530, Devin Teske wrote:
> > > >
> > > >
> > > > > On Jan 25, 2019, at 12:28 AM, Edward Napierala <
> > > > > trasz at freebsd.org> wrote:
> > > > >
> > > > > On 0125T1441, Devin Teske wrote:
> > > > > >
> > > > > >
> > > > > > > On Jan 25, 2019, at 1:37 PM, Edward Napierala <
> > > > > > > trasz at freebsd.org> wrote:
> > > > > > >
> > > > > > > pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> > > > > > > <freebsd at pdx.rh.cn85.dnsmgr.net <mailto:
> > > > > > > freebsd at 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.
>
>