linux-kernel - Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

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] [day] [month] [year] [list]

Message-ID: <CAHC9VhSd8ftho=vRLr_jQQVxA9LK+7zrDyKcoYvRCM-sCoz7ZQ@mail.gmail.com>
Date:   Mon, 13 Nov 2017 14:01:30 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Steve Grubb <sgrubb@...hat.com>,
        Richard Guy Briggs <rgb@...hat.com>
Cc:     linux-audit@...hat.com, linux-kernel@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with
 anonymous parents

On Mon, Nov 13, 2017 at 1:30 PM, Steve Grubb <sgrubb@...hat.com> wrote:
> On Thursday, November 9, 2017 3:52:46 PM EST Richard Guy Briggs wrote:
>> > >> > It might be simplest to just apply a corrective patch over top of
>> > >> > this one so that you don't have to muck about with git branches and
>> > >> > commit messages.
>> > >>
>> > >> A quick note on the "corrective patch": given we are just days away
>> > >> from the merge window opening, it is *way* to late for something like
>> > >> that, at this point the only options are to leave it as-is or
>> > >> yank/revert and make another pass during the next development phase.
>> > >
>> > > Then yank it. I think that is overreacting but given the options you
>> > > presented its the only one that avoids changing a critical field
>> > > format.
>> >
>> > It's not overreacting Steve, there is simply no way we can test and
>> > adequately soak new changes in the few days we have left.
>
> Its just moving the output of the information a few lines down further in the
> code. 10 minutes of work, tops.

It's like you don't even bother reading why I write ... it's not about
the amount of time needed to make the change, it's the other stuff I
mentioned.  Regardless, it's a moot point now, the patch is out and it
isn't going up in the currently open merge window.

>> > Event yanks/reverts carry a risk at this stage, but I consider that the
>> > less risky option for these patches.  Neither is a great option, and that
>> > is why I'm rather annoyed.
>>
>> I don't really see that this is my choice to include it or not.  This is
>> the upstream maintainer's decision.
>>
>> I can't say I'd be thrilled to have my name on something that stuffs up
>> the system though.  It still isn't clear to me why an incomplete path
>> from some seemingly random place in the filesystem tree is preferable to
>> something that gives it an anchor point, at least to human interpreters.
>
> The path should stay. Just the file system type needs decoupling and moving.

See my previous comments about relative pathnames, specifially the
part about me not being a fan of them in the PATH records.

-- 
paul moore
www.paul-moore.com