Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Sam Liddicott <sam@liddicott.com>
Newsgroups: gnu.bash.bug
Subject: Re: %q with truncating size loses safeness of %q
Date: Sat, 18 Apr 2020 08:16:31 +0100
Lines: 65
Approved: bug-bash@gnu.org
Message-ID: <mailman.566.1587194221.3066.bug-bash@gnu.org>
References: <CAOj-5WCqxqh=Gcda9k6y4orQaQYXPgsOgNEOVN1AdZQrkCVbtg@mail.gmail.com> <4bacf2f0-9802-67d3-f30b-80e37d058a4a@case.edu> <22039.1587163072@jinx.noi.kre.to> <CAOj-5WDk0Y5O=NLvzOJSxohHJQkW4OLV0Me6NUyp_1EpnYx9jg@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Chester Ramey <chet.ramey@case.edu>, bug-bash@gnu.org
To: Robert Elz <kre@munnari.oz.au>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <22039.1587163072@jinx.noi.kre.to>
Precedence: list
Xref: csiph.com gnu.bash.bug:16164

In my case I was using process substitution to generate a dynamic bashrc
file as part of invoking an SDK environment.

Naturally those lines which emit environment variable assignments use %q

I had one build version tracking variable which was to be limited to 7
characters and set to a lowercase form of the username.

The most concise but surprisingly unsafe form is.

printf 'BUILD_VER_SUFFIX=%.7q\n' "${USER,,}"

That's clearly not artificially contrived; (though the user has the ability
to directly mess up their build environment anyway if they so wish).

The answer is obviously "don't do that" but it that requires a special
obscure knowledge which isn't documented.

Can we have bash printf to also not do that? Or if it must break the
security feature got which it exists can at least be documented?

I think I've made myself clear so I went harp on about it anymore unless I
find a more egregious opportunity for abuse.

Sam


On Fri, 17 Apr 2020, 23:38 Robert Elz, <kre@munnari.oz.au> wrote:

>     Date:        Fri, 17 Apr 2020 16:12:20 -0400
>     From:        Chet Ramey <chet.ramey@case.edu>
>     Message-ID:  <4bacf2f0-9802-67d3-f30b-80e37d058a4a@case.edu>
>
>   | I would say this is a programmer error.  The way precisions work with
>   | string arguments is that the argument is fetched or generated (this
>   | includes generating the quoted string for %q or the expanded string for
>   | %b) and then printf writes number of bytes (!) from that generated
> string
>   | specified by the precision.
>
> This happens only because of the cheap way we (and I presume you)
> implement things - in any rational scheme, it would take the precision
> chars from the source string, and then quote them.
>
> But that's hard - instead we just use printf to do the work, %q quotes
> the arg string, and then the 'q' is changed to a 's' in the format, and
> we just call printf(3) to do the work (padding, justification, ...)
>
> The only excuse for this is pragmatics, no-one would deliberately set
> out to design something quite that bogus.
>
> The end result is as Greg said, "Don't do that", if precisions are
> needed with %q do something like
>
>         printf 'echo %q%q\n' "$(printf %.2s "a'b")" ';ls'
>
> which produces
>
>         echo a\'\;ls
>
> which I expect is the desired result.
>
> kre
>
>