linux-kernel - Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Apr 2016 13:16:53 -0400 (EDT)
From:	martin@...ibond.com
To:	Andy Shevchenko <andy.shevchenko@...il.com>
cc:	Mike Marshall <hubcap@...ibond.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

On Fri, 8 Apr 2016, Andy Shevchenko wrote:

> On Fri, Apr 8, 2016 at 6:34 PM,  <martin@...ibond.com> wrote:
> >> On Thu, Apr 7, 2016 at 2:39 PM, Andy Shevchenko
> >> <andy.shevchenko@...il.com> wrote:
> >> > On Mon, Apr 4, 2016 at 11:26 PM, Martin Brandenburg <martin@...ibond.com> wrote:
> >> >> From: Martin Brandenburg <martin@...ibond.com>
> >> >>
> >> >> Almost everywhere we use strncpy we should use strlcpy. This affects
> >> >> path names (d_name mostly), symlink targets, and server names.
> >> >>
> >> >> Leave debugfs code as is for now, though it could use a review as well.
> >> >>
> >> >
> >> > |Why not strscpy() as most robust one?
> >
> > Mostly because I hadn't heard about strscpy.
> 
> It was nice story how he applied it to the tree.

Just read it..

> 
> >> It looks like strscpy went in last October... there are
> >> no users of it yet. I was just about to send in a pull request
> >> that includes Martin's strncpy->strlcpy patch when I saw
> >> Andy's comment.
> >>
> >> Linus said when he pulled strscpy:
> 
> > After looking over strscpy I don't see a compelling
> > reason not to go ahead and use it while we're fixing up
> > this code.
> 
> I recommend to mention that this is a fix explicitly in the commit
> message, currently it sounds like a meaningless patch of trainee.

I've decided to scrap most of this, but one change is
important. Most of it is a no-op because the client-core
buffer is larger than NAME_MAX and there is always room.
Replying with patch in a minute.

Thanks for the review!

Mike, I think we can delay this one for later so we can
look at the debugfs and superblock code in more detail.

-- Martin

> 
> -- 
> With Best Regards,
> Andy Shevchenko
>