linux-kernel - Re: [PATCH 2/2] selinux: move genheaders to security/selinux/

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]

Message-ID: <CAHC9VhRhUPTwg2-wsLzGGpbhG_4sH9K5o6Z5D_aLiiO98LgaJQ@mail.gmail.com>
Date: Fri, 6 Sep 2024 12:22:57 -0400
From: Paul Moore <paul@...l-moore.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-security-module@...r.kernel.org, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Daniel Gomez <da.gomez@...sung.com>, 
	Ondrej Mosnacek <omosnace@...hat.com>, Stephen Smalley <stephen.smalley.work@...il.com>, 
	selinux@...r.kernel.org
Subject: Re: [PATCH 2/2] selinux: move genheaders to security/selinux/

On Fri, Sep 6, 2024 at 12:06 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> On Sat, Sep 7, 2024 at 12:37 AM Paul Moore <paul@...l-moore.com> wrote:
> > On Fri, Sep 6, 2024 at 11:19 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
> > > On Tue, Aug 27, 2024 at 6:22 AM Paul Moore <paul@...l-moore.com> wrote:
> > > > On Aug  9, 2024 Masahiro Yamada <masahiroy@...nel.org> wrote:
> > > > >
> > > > > This tool is only used in security/selinux/Makefile.
> > > > >
> > > > > There is no reason to keep it under scripts/.
> > > > >
> > > > > Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> > > > > ---
> > > > >  scripts/remove-stale-files                                 | 3 +++
> > > > >  scripts/selinux/Makefile                                   | 2 +-
> > > > >  scripts/selinux/genheaders/.gitignore                      | 2 --
> > > > >  scripts/selinux/genheaders/Makefile                        | 3 ---
> > > > >  security/selinux/.gitignore                                | 1 +
> > > > >  security/selinux/Makefile                                  | 7 +++++--
> > > > >  .../selinux/genheaders => security/selinux}/genheaders.c   | 0
> > > > >  7 files changed, 10 insertions(+), 8 deletions(-)
> > > > >  delete mode 100644 scripts/selinux/genheaders/.gitignore
> > > > >  delete mode 100644 scripts/selinux/genheaders/Makefile
> > > > >  rename {scripts/selinux/genheaders => security/selinux}/genheaders.c (100%)
> > > >
> > > > As long as there is no harm in keeping genheaders under scripts/selinux,
> > > > and based on your cover letter it would appear that there is no problem
> > > > with the current location, I would prefer to keep it where it currently
> > > > lives.
> > >
> > > 'make clean' is meant to clean up the tree, but keep
> > > build artifacts necessary for building external modules.
> > >
> > > See the help message:
> > >
> > >   clean           - Remove most generated files but keep the config and
> > >                     enough build support to build external modules
> > >
> > > 'make clean' does not clean up under scripts/
> > > because tools located scripts/ are used in tree-wide
> > > and often used for external modules as well.
> > >
> > > So, scripts/selinux/genheaders/genheaders is left over.
> > >
> > > genheaders is locally used in security/selinux/.
> > >
> > > 'make clean' will properly clean up security/selinux/genheaders.
> >
> > Your last sentence is confusing and doesn't align with the rest of
> > your email, please clarify.
>
> I do not understand what was unclear.

Near the start of your email you stated: "'make clean' does not clean
up under scripts/".  However you ended your email with "'make clean'
will properly clean up security/selinux/genheaders" which seems
contradictory to your initial statement; I was guessing that you were
implying that moving the genheaders script will allow `make clean` to
work properly, but you explicitly included the old/existing location
of security/selinux/genheaders directory in your comment which didn't
support that guess.

Your latest reply makes it a bit more clear.

-- 
paul-moore.com