All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Solar Designer <solar@openwall.com>,
	Ernie Petrides <petrides@redhat.com>,
	linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: printk()s of user-supplied strings
Date: Wed, 30 Aug 2006 08:15:17 +0200	[thread overview]
Message-ID: <20060830061517.GA282@1wt.eu> (raw)
In-Reply-To: <m3sljhp0rs.fsf@defiant.localdomain>

On Mon, Aug 28, 2006 at 01:17:43PM +0200, Krzysztof Halasa wrote:
> Willy Tarreau <w@1wt.eu> writes:
> 
> > Well, I'm not sure about this. Nearly all patches which get merged pass
> > through a public review first, and when you see how many replies you get
> > for and 'else' and and 'if' on two different lines, I expect lots of
> > spontaneous replies such as "use %S for user-supplied strings".
> 
> I wouldn't rely on that.
> 
> >> A solution would be to normally use "%S" and only use
> >> "%s" where "%S" wouldn't work.  In that case, we could as well swap "%s"
> >> and "%S", though - hardening the existing "%s" and introducing "%S" for
> >> those callers that depend on the old behavior.
> 
> I think it's the way to go.
> 
> > I'd rather not change "%s" semantics if we introduce another specifier
> > which does exactly what we would expect "%s" to do.
> 
> Both would be equivalent in most cases. It's better to use "%s" for
> most cases (either secured or not) and leave "%S" for the bunch of
> special cases whose authors better know what are they doing.
> 
> > I will try your proposal to retain the trailing '\n' unescaped.
> 
> I think with "%s" and "%S" this is no longer needed.

Yes it will be for compatibility reasons : we for sure will not fix all
users of "%s" quickly, so we will have to do our best not to break them.
If it was easy to find them all, we could replace "%s" with "%S" everywhere
and make "%S" the escaped one.

But well, I believe that you convinced me that escaping the "%s" and providing
a new "%S" for secure or special usages might be the way to go.

I will propose a patch soon.

> Krzysztof Halasa

thanks,
willy


  reply	other threads:[~2006-08-30  6:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-20  2:04 [PATCH x7] misc fixes from 2.4.33-ow1 Solar Designer
2006-08-20  9:15 ` [PATCH] binfmt_elf.c : the BAD_ADDR macro again Willy Tarreau
2006-08-20 15:51   ` Solar Designer
2006-08-20 16:23     ` Willy Tarreau
2006-08-21 20:35       ` Ernie Petrides
2006-08-21 21:11         ` Willy Tarreau
2006-08-21 23:36           ` Ernie Petrides
2006-08-22  3:07             ` printk()s of user-supplied strings (Re: [PATCH] binfmt_elf.c : the BAD_ADDR macro again) Solar Designer
2006-08-22 20:23               ` Ernie Petrides
2006-08-22 20:34                 ` printk()s of user-supplied strings Willy Tarreau
2006-08-24 16:44                 ` printk()s of user-supplied strings (Re: [PATCH] binfmt_elf.c : the BAD_ADDR macro again) Solar Designer
2006-08-24 16:46                   ` Willy Tarreau
2006-08-26  2:29                     ` Solar Designer
2006-08-26  8:22                       ` Willy Tarreau
2006-08-26 23:13                         ` Solar Designer
2006-08-27 20:04                           ` printk()s of user-supplied strings Willy Tarreau
2006-08-28  1:52                             ` Solar Designer
1970-01-01  0:16                               ` Pavel Machek
2006-08-28  8:02                               ` Willy Tarreau
2006-08-28 11:17                                 ` Krzysztof Halasa
2006-08-30  6:15                                   ` Willy Tarreau [this message]
2006-08-28 17:35                               ` Valdis.Kletnieks
2006-08-22  4:36             ` [PATCH] binfmt_elf.c : the BAD_ADDR macro again Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060830061517.GA282@1wt.eu \
    --to=w@1wt.eu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petrides@redhat.com \
    --cc=solar@openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.