From: Paul Moore <paul@paul-moore.com>
To: luca.boccassi@gmail.com
Cc: linux-kernel@vger.kernel.org, christian@brauner.io,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] pidfd: add ioctl to retrieve pid info
Date: Wed, 2 Oct 2024 10:48:32 -0400 [thread overview]
Message-ID: <CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com> (raw)
In-Reply-To: <20241002142516.110567-1-luca.boccassi@gmail.com>
On Wed, Oct 2, 2024 at 10:25 AM <luca.boccassi@gmail.com> wrote:
>
> From: Luca Boccassi <bluca@debian.org>
>
> A common pattern when using pid fds is having to get information
> about the process, which currently requires /proc being mounted,
> resolving the fd to a pid, and then do manual string parsing of
> /proc/N/status and friends. This needs to be reimplemented over
> and over in all userspace projects (e.g.: I have reimplemented
> resolving in systemd, dbus, dbus-daemon, polkit so far), and
> requires additional care in checking that the fd is still valid
> after having parsed the data, to avoid races.
>
> Having a programmatic API that can be used directly removes all
> these requirements, including having /proc mounted.
>
> As discussed at LPC24, add an ioctl with an extensible struct
> so that more parameters can be added later if needed. Start with
> exposing: pid, uid, gid, groupid, security label (the latter was
> requested by the LSM maintainer).
>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> fs/pidfs.c | 61 ++++++++++++++++++-
> include/uapi/linux/pidfd.h | 17 ++++++
> .../testing/selftests/pidfd/pidfd_open_test.c | 50 ++++++++++++++-
> 3 files changed, 126 insertions(+), 2 deletions(-)
...
> diff --git a/include/uapi/linux/pidfd.h b/include/uapi/linux/pidfd.h
> index 565fc0629fff..bfd0965e01f3 100644
> --- a/include/uapi/linux/pidfd.h
> +++ b/include/uapi/linux/pidfd.h
> @@ -16,6 +16,22 @@
> #define PIDFD_SIGNAL_THREAD_GROUP (1UL << 1)
> #define PIDFD_SIGNAL_PROCESS_GROUP (1UL << 2)
>
> +/* Flags for pidfd_info. */
> +#define PIDFD_INFO_PID (1UL << 0)
> +#define PIDFD_INFO_CREDS (1UL << 1)
> +#define PIDFD_INFO_CGROUPID (1UL << 2)
> +#define PIDFD_INFO_SECURITY_CONTEXT (1UL << 3)
> +
> +struct pidfd_info {
> + __u64 request_mask;
> + __u32 size;
> + uint pid;
> + uint uid;
> + uint gid;
> + __u64 cgroupid;
> + char security_context[NAME_MAX];
[NOTE: please CC the LSM list on changes like this]
Thanks Luca :)
With the addition of the LSM syscalls we've created a lsm_ctx struct
(see include/uapi/linux/lsm.h) that properly supports multiple LSMs.
The original char ptr "secctx" approach worked back when only a single
LSM was supported at any given time, but now that multiple LSMs are
supported we need something richer, and it would be good to use this
new struct in any new userspace API.
See the lsm_get_self_attr(2) syscall for an example (defined in
security/lsm_syscalls.c but effectively implemented via
security_getselfattr() in security/security.c).
> +} __packed;
> +
> #define PIDFS_IOCTL_MAGIC 0xFF
>
> #define PIDFD_GET_CGROUP_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 1)
> @@ -28,5 +44,6 @@
> #define PIDFD_GET_TIME_FOR_CHILDREN_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 8)
> #define PIDFD_GET_USER_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 9)
> #define PIDFD_GET_UTS_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 10)
> +#define PIDFD_GET_INFO _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info)
>
> #endif /* _UAPI_LINUX_PIDFD_H */
--
paul-moore.com
next parent reply other threads:[~2024-10-02 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20241002142516.110567-1-luca.boccassi@gmail.com>
2024-10-02 14:48 ` Paul Moore [this message]
2024-10-04 18:48 ` [PATCH] pidfd: add ioctl to retrieve pid info Luca Boccassi
2024-10-05 16:05 ` Paul Moore
2024-10-22 23:45 ` luca.boccassi
2024-10-22 23:56 ` Luca Boccassi
2024-10-24 23:14 ` Paul Moore
2024-10-24 23:31 ` Luca Boccassi
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='CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=christian@brauner.io \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luca.boccassi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).