linux-kernel - Re: selinux: Adjust implementation of security_get

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

Message-ID: <CAHC9VhQfiNd_4uWBmKCC81UnOJb7Y=UFCDMXuqz3=UPr8QtqNw@mail.gmail.com>
Date:   Tue, 28 Mar 2023 15:59:51 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Markus Elfring <Markus.Elfring@....de>
Cc:     kernel-janitors@...r.kernel.org, selinux@...r.kernel.org,
        Christian Göttsche <cgzones@...glemail.com>,
        Eric Paris <eparis@...isplace.org>,
        Michal Orzel <michalorzel.eng@...il.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Ruiqi Gong <gongruiqi1@...wei.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Xiu Jianfeng <xiujianfeng@...wei.com>, cocci@...ia.fr,
        LKML <linux-kernel@...r.kernel.org>,
        Ruiqi Gong <ruiqi.gong@...com>
Subject: Re: selinux: Adjust implementation of security_get_bools()

On Tue, Mar 28, 2023 at 3:30 AM Markus Elfring <Markus.Elfring@....de> wrote:
>
> …
> >>>  security/selinux/ss/services.c | 52 ++++++++++++++--------------------
> …
> > Given the fairly extensive refactoring here,
> …
> > If nothing else it will make the function easier to read,
> > and I think it will simplify the code a bit too.
>
> I am curious which change possibilities will finally be picked up.

It's hard to extract out the various changes due to the way the diff
was generated, however, looking at the changes in your commit
description, the only change I can saw with any certainty that I would
merge would be your item #2:

> 2. Replace the statement “goto out;” by “return -ENOMEM;”.

Agreed, gotos that jump straight to a return can be replaced.

> > I would probably also keep the combined @names/@...ues cleanup under
> > one jump label; this function isn't complicated enough to warrant that
> > many jump labels for error conditions.
>
> I got an other impression for the affected function implementation.
>
> Would you like to take advice from another information source
> better into account?

In this case, I prefer what I suggested.

-- 
paul-moore.com