lkml.org 
[lkml]   [2022]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 3/5] selinux: use consistent pointer types for boolean arrays
On Fri, 18 Feb 2022 at 17:01, Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Feb 17, 2022 at 9:21 AM Christian Göttsche
> <cgzones@googlemail.com> wrote:
> >
> > Use a consistent type of unsigned int* for boolean arrays, instead of
> > using implicit casts to and from int*.
> >
> > Reported by sparse:
> >
> > security/selinux/selinuxfs.c:1481:30: warning: incorrect type in assignment (different signedness)
> > security/selinux/selinuxfs.c:1481:30: expected unsigned int *
> > security/selinux/selinuxfs.c:1481:30: got int *[addressable] values
> > security/selinux/selinuxfs.c:1398:48: warning: incorrect type in argument 3 (different signedness)
> > security/selinux/selinuxfs.c:1398:48: expected int *values
> > security/selinux/selinuxfs.c:1398:48: got unsigned int *bool_pending_values
> >
> > Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> >
> > ---
> > A more invasive change would be to change all boolean arrays to bool*.
>
> I think that might be a worthwhile change, although that can happen at
> a later date.
>
> A quick general comment: please try to stick to 80-char long lines. I
> realize Linus/checkpatch.pl has started to allow longer lines but I
> would still like SELinux to try and keep to 80-chars or under.
>
> > diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> > index 6901dc07680d..7865926962ab 100644
> > --- a/security/selinux/ss/services.c
> > +++ b/security/selinux/ss/services.c
> > @@ -3175,7 +3175,8 @@ int security_get_bool_value(struct selinux_state *state,
> > static int security_preserve_bools(struct selinux_policy *oldpolicy,
> > struct selinux_policy *newpolicy)
> > {
> > - int rc, *bvalues = NULL;
> > + int rc;
> > + unsigned int *bvalues = NULL;
>
> Doesn't this cause a type mismatch (unsigned int vs int) when an entry
> from bvalues[] is assigned to cond_bool_datum::state later in the
> security_preserve_bools() function?

Yes, but those variables *should* only hold the values 0 or 1.
But probably it's better to re-spin for 5.19 with all arrays and
cond_bool_datum::state converted to literal bool type.

>
> --
> paul-moore.com

\
 
 \ /
  Last update: 2022-03-08 16:59    [W:0.057 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site