linux-kernel - Re: [PATCH] namei: revert old behaviour for filename_lookup with LOOKUP

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:   Thu, 13 Oct 2016 15:14:23 -0700
From:   Vineeth Remanan Pillai <vineethp@...zon.com>
To:     Al Viro <viro@...IV.linux.org.uk>
CC:     Christoph Hellwig <hch@...radead.org>,
        <linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kamatam@...zon.com>, <aliguori@...zon.com>
Subject: Re: [PATCH] namei: revert old behaviour for filename_lookup with
 LOOKUP_PARENT flag


On 10/13/2016 02:24 PM, Al Viro wrote:
> On Thu, Oct 13, 2016 at 01:41:11PM -0700, Vineeth Remanan Pillai wrote:
>
>> Yes, the use case is out-of-tree and the code snippet above depicts the use
>> .
>> Since kern_path_locked is also not exported, out-of-tree code used kern_path
>> for the existence check for directories.
>>
>> One reference about this issue can be seen here.
>>
>> http://www.gossamer-threads.com/lists/linux/kernel/2459690?do=post_view_flat#2459690
> ... and in that thread I have asked for details and got no reply whatsoever.
>   
>> We also have a customer who complained about this functionality change.
>>
>> I understand that there has been no API promises been made to this API. But
>> since this is an
>> exported function, the change in function could cause break in out-of-tree
>> kernel code. I will
>> rephrase the commit message to say "change in functionality" instead of
>> regression
> In principle, I have no strong objections against exporting kern_path_locked,
> provided it really matches what they (whoever they are) need.  I'm still
> curious about the context, though - what is that code trying to do?  Depending
> on the actual stuff it wants to implement, there might be better primitives
> for doing that *and* there might be something worth adding and exporting
> that would be a better match.
>
> It's not that kern_path_locked() isn't a sane interface, but... using it
> might be a sign of trying to work around something missing in API.  So again,
> please post more details.
Unfortunately, I also do not have enough context about the customer
code that uses it. Since kern_path was exported function and the
behavior changed across releases, this patch is just trying to revert
to the old behavior.
I clearly get what you are trying to say. It would have been really
beneficial to get the context so as to understand use case and figure out
alternative or better approach. But I think we should have the functionality
as before and if kern_path is not the right API for this purpose, 
probably we
should deprecate it in a phased manner.