[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhRgw+xphjO+vBUuf45DJMTau-PzRY_ZxqWxpg-K0u+pDA@mail.gmail.com>
Date: Sun, 24 Dec 2023 15:09:45 -0500
From: Paul Moore <paul@...l-moore.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Alfred Piccioni <alpic@...gle.com>, Stephen Smalley <stephen.smalley.work@...il.com>,
Eric Paris <eparis@...isplace.org>, linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, stable@...r.kernel.org,
selinux@...r.kernel.org, linux-kernel@...r.kernel.org,
Casey Schaufler <casey@...aufler-ca.com>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [PATCH] security: new security_file_ioctl_compat() hook
On Sun, Dec 24, 2023 at 3:00 PM Paul Moore <paul@...l-moore.com> wrote:
> On Sat, Dec 23, 2023 at 10:34 AM Eric Biggers <ebiggers@...nel.org> wrote:
> > On Fri, Dec 22, 2023 at 08:23:26PM -0500, Paul Moore wrote:
> > > Is it considered valid for a native 64-bit task to use 32-bit
> > > FS_IO32_XXX flags?
> >
> > No, that's not valid.
>
> Excellent, thank you.
>
> > > If not, do we want to remove the FS_IO32_XXX flag
> > > checks in selinux_file_ioctl()?
> >
> > I don't see any such flag checks in selinux_file_ioctl().
>
> Neither do I ... I'm not sure what I was looking at when I made that
> comment, I'm going to chalk that up to a bit of holiday fog. Sorry
> for the noise.
Ah ha, I think I found the problem - the tools I use to pull in
patches for review seemed to have grabbed an old version of the patch
that *did* as the 32-bit ioctl commands to selinux_file_ioctl().
https://lore.kernel.org/selinux/20230906102557.3432236-1-alpic@google.com/
--
paul-moore.com
Powered by blists - more mailing lists