All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alfred Piccioni <alpic@google.com>
To: Paul Moore <paul@paul-moore.com>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	 Eric Paris <eparis@parisplace.org>
Cc: linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,  stable@vger.kernel.org,
	selinux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] security: new security_file_ioctl_compat() hook
Date: Tue, 19 Dec 2023 10:10:38 +0100	[thread overview]
Message-ID: <CALcwBGC9LzzdJeq3SWy9F3g5A32s5uSvJZae4j+rwNQqqLHCKg@mail.gmail.com> (raw)
In-Reply-To: <20231219090909.2827497-1-alpic@google.com>

Thanks for taking the time to review! Apologies for the number of
small mistakes.

> s/syscal/syscall/
> Might to consider checking using codespell to catch such things
> although it is imperfect.

Fixed, loaded codespell.

> Paul doesn't like C++-style comments so rewrite using kernel coding
> style for multi-line comments or drop.
> I don't think kernel coding style strictly prohibits use for
> single-line comments and it isn't detected by checkpatch.pl but he has
> previously
> raised this on other patches. I actually like the C++-style comments
> for one-liners especially for comments at the end of a line of code
> but Paul is the maintainer so he gets the final word.

Changed to /**/ style comments. No particular preference on my side
for comment structure, just used to C++/Java style.

> Sorry, missed this the first time but cut-and-paste error above:
> s/GETFLAGS/SETFLAGS/

Egads. Fixed.

> Also, IIRC, Paul prefers putting a pair of parentheses after function
> names to distinguish them, so in the subject line
> and description it should be security_file_ioctl_compat() and
> security_file_ioctl(), and you should put a patch version
> in the [PATCH] prefix e.g. [PATCH v3] to make clear that it is a later
> version, and usually one doesn't capitalize SELinux
> or the leading verb in the subject line (just "selinux: introduce").

Changed title to lower-case, prefixed with security, changed slightly
to fit in summary with new parentheses. Added [PATCH V3] to the
subject.

> Actually, since this spans more than just SELinux, the prefix likely
> needs to reflect that (e.g. security: introduce ...)
> and the patch should go to the linux-security-module mailing list too
> and perhaps linux-fsdevel for the ioctl change.

Added cc 'selinux@vger.kernel.org' and cc
'linux-kernel@vger.kernel.org'. Thanks!

> I didn't do an audit but does anything need to be updated for the BPF
> LSM or does it auto-magically pick up new hooks?

I'm unsure. I looked through the BPF LSM and I can't see any way it's
picking up the file_ioctl hook to begin with. It appears to me
skimming through the code that it automagically picks it up, but I'm
not willing to bet the kernel on it.

Do you know who would be a good person to ask about this to make sure?

  reply	other threads:[~2023-12-19  9:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-06 10:25 [PATCH] SELinux: Check correct permissions for FS_IOC32_* Alfred Piccioni
2023-09-06 10:28 ` kernel test robot
2023-09-06 11:59 ` [PATCH V2] " Alfred Piccioni
2023-09-06 17:49   ` Stephen Smalley
2023-09-08 22:54   ` kernel test robot
2023-09-11 13:19     ` Stephen Smalley
2023-09-11 13:49       ` Stephen Smalley
2023-09-12  9:00         ` Alfred Piccioni
2023-09-12 12:00           ` Stephen Smalley
2023-09-12 15:46             ` Mickaël Salaün
2023-09-13  3:52       ` Paul Moore
2023-12-18 12:41 ` [PATCH] SELinux: Introduce security_file_ioctl_compat hook Alfred Piccioni
2023-12-18 13:46   ` Stephen Smalley
2023-12-18 13:50     ` Stephen Smalley
2023-12-19  9:09 ` [PATCH] security: new security_file_ioctl_compat() hook Alfred Piccioni
2023-12-19  9:10   ` Alfred Piccioni [this message]
2023-12-20 14:38     ` Alfred Piccioni
2023-12-20 15:34     ` Stephen Smalley
2023-12-23 11:15     ` Fwd: " Tetsuo Handa
2023-12-23 14:41     ` Tetsuo Handa
2023-12-20 17:31   ` Stephen Smalley
2023-12-20 18:48   ` Eric Biggers
2023-12-23  1:23   ` Paul Moore
2023-12-23 10:48     ` Tetsuo Handa
2023-12-24 19:58       ` Paul Moore
2023-12-23 15:34     ` Eric Biggers
2023-12-24 20:00       ` Paul Moore
2023-12-24 20:09         ` Paul Moore
2023-12-23 17:54     ` Casey Schaufler
2023-12-24 20:53   ` Paul Moore
2023-12-27  4:43     ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALcwBGC9LzzdJeq3SWy9F3g5A32s5uSvJZae4j+rwNQqqLHCKg@mail.gmail.com \
    --to=alpic@google.com \
    --cc=eparis@parisplace.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.