From: sashiko-bot@kernel.org
To: "Jan Koester" <jan.koester@tuxist.de>,
"Christian Brauner" <brauner@kernel.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Serge E. Hallyn" <serge@hallyn.com>
Cc: "Jan Kara" <jack@suse.cz>, "Theodore Y. Ts'o" <tytso@mit.edu>,
"Paul Moore" <paul@paul-moore.com>,
"Arnd Bergmann" <arnd@arndb.de>,
linux-security-module@vger.kernel.org,
linux-ext4@vger.kernel.org, audit@vger.kernel.org,
keyrings@vger.kernel.org, "Chuck Lever" <cel@kernel.org>,
"Jeff Layton" <jlayton@kernel.org>,
"Anna Schumaker" <anna@kernel.org>
Subject: Re: [RFC PATCH v2 31/41] ext4: add the uid_r feature for UUID and GUID owners
Date: Thu, 22 Oct 2026 03:17:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-180932@kernel.org> (raw)
In-Reply-To: <1ced8bf416de4e9600904aafeefd29ed20fd2064.1792552161.git.jan.koester@tuxist.de>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] ext4: unverified extra_isize expansion in ext4_make_room_for_id_r()
- [Medium] ext4: UUID/GUID owners lost in ext4_xattr_inode_create() and ext4_ext_migrate()
- [Medium] ext4: debug_want_extra_isize can set s_want_extra_isize too small for uid_r
- [Medium] ext4: NO_UID32 clobbers 0xffffffff sentinel in ext4_fill_raw_inode()
- [Medium] ext4: race in ext4_make_room_for_id_r() with concurrent inode expansion
- [Medium] ext4: unsynchronized 20-byte i_uid and i_gid accesses in ext4_fill_raw_inode()
--
commit f1bc4b92fd7bffda167e28ce9ca4459d00337211
Author: Jan Koester <jan.koester@tuxist.de>
ext4: add the uid_r feature for UUID and GUID owners
This commit adds the read-only compatible uid_r feature to ext4, extending
struct ext4_inode with i_uid_r_type, i_gid_r_type, i_uid_r, and i_gid_r to
store 16-byte UUID and GUID owners and groups while storing 0xffffffff in
the classic i_uid and i_gid fields. It also sets SB_I_UID_R on the
superblock and expands existing inodes in ext4_setattr() when assigning a
UUID or GUID owner or group.
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 26f0f9714f03c..bed8d535a6e4e 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4780,6 +4780,75 @@ static int ext4_inode_blocks_set(struct ext4_inode *raw_inode,
> return 0;
> }
>
> +/*
> + * uid_r: a UUID or GUID owner and group live in i_uid_r and i_gid_r of
> + * inodes with room for them; i_uid and i_gid then hold 0xffffffff.
> + */
> +static int ext4_inode_set_id_r(struct inode *inode, struct ext4_inode *raw_inode)
> +{
> + struct ext4_inode_info *ei = EXT4_I(inode);
> + bool fits = EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE &&
> + EXT4_FITS_IN_INODE(raw_inode, ei, i_gid_r);
> + bool legacy = uid_is_legacy(inode->i_uid) && gid_is_legacy(inode->i_gid);
> +
> + if (!legacy && (!ext4_has_feature_uid_r(inode->i_sb) || !fits))
> + return -EOVERFLOW;
> + if (!fits || !ext4_has_feature_uid_r(inode->i_sb))
> + return 0;
> +
> + raw_inode->i_id_r_reserved = 0;
> + if (uid_is_legacy(inode->i_uid)) {
> + raw_inode->i_uid_r_type = EXT4_ID_R_LEGACY;
> + memset(raw_inode->i_uid_r, 0, sizeof(raw_inode->i_uid_r));
> + } else {
> + BUILD_BUG_ON(KID_UUID != EXT4_ID_R_UUID ||
> + KID_GUID != EXT4_ID_R_GUID);
> + raw_inode->i_uid_r_type = inode->i_uid.type;
> + memcpy(raw_inode->i_uid_r, inode->i_uid.uuid.b,
> + sizeof(raw_inode->i_uid_r));
> + }
> + if (gid_is_legacy(inode->i_gid)) {
> + raw_inode->i_gid_r_type = EXT4_ID_R_LEGACY;
> + memset(raw_inode->i_gid_r, 0, sizeof(raw_inode->i_gid_r));
> + } else {
> + raw_inode->i_gid_r_type = inode->i_gid.type;
> + memcpy(raw_inode->i_gid_r, inode->i_gid.uuid.b,
> + sizeof(raw_inode->i_gid_r));
> + }
> + return 0;
> +}
[Severity: Medium]
With UUID and GUID support, kuid_t and kgid_t are 20-byte structures, so
reads and writes of inode->i_uid and inode->i_gid are multi-word and not
atomic.
In fs/ext4/inode.c, ext4_setattr() updates inode->i_uid and inode->i_gid
under inode->i_rwsem without holding EXT4_I(inode)->i_raw_lock:
fs/ext4/inode.c:ext4_setattr() {
...
i_uid_update(idmap, attr, inode);
i_gid_update(idmap, attr, inode);
error = ext4_mark_inode_dirty(handle, inode);
}
Concurrently, paths that dirty the inode without holding inode->i_rwsem
(such as touch_atime() -> ext4_dirty_inode(), or unwritten extent
conversion in ext4_end_io_rsv_work() -> ext4_mark_inode_dirty()) call
ext4_do_update_inode() -> ext4_fill_raw_inode() -> ext4_inode_set_id_r()
under ei->i_raw_lock, and __ext4_get_inode_loc() also calls
ext4_fill_raw_inode() under lock_buffer(bh).
Because ext4_fill_raw_inode() first reads inode->i_uid and inode->i_gid via
i_uid_read() and i_gid_read(), and ext4_inode_set_id_r() then re-reads
inode->i_uid and inode->i_gid multiple times, can a concurrent chown race
with ext4_fill_raw_inode() and write a torn 16-byte UUID/GUID or mismatched
classic i_uid/i_gid and i_uid_r/i_gid_r fields (with a valid metadata
checksum computed over that inconsistent state) into raw_inode?
[ ... ]
> @@ -4792,8 +4861,10 @@ static int ext4_fill_raw_inode(struct inode *inode, struct ext4_inode *raw_inode
> err = ext4_inode_blocks_set(raw_inode, ei);
>
> raw_inode->i_mode = cpu_to_le16(inode->i_mode);
> + /* a UUID or GUID owner: 0xffffffff here, the id in i_uid_r */
> i_uid = i_uid_read(inode);
> i_gid = i_gid_read(inode);
> + err = err ?: ext4_inode_set_id_r(inode, raw_inode);
[Severity: Medium]
When an inode has a UUID or GUID owner or group, i_uid_read(inode) and
i_gid_read(inode) return (uid_t)-1 (0xffffffff).
Both ext4_xattr_inode_create() in fs/ext4/xattr.c and ext4_ext_migrate() in
fs/ext4/migrate.c copy the parent inode's owner into a uid_t owner[2] array
using i_uid_read() and i_gid_read() and pass that array to ext4_new_inode():
fs/ext4/xattr.c:ext4_xattr_inode_create() {
struct inode *ea_inode = NULL;
uid_t owner[2] = { i_uid_read(inode), i_gid_read(inode) };
...
ea_inode = ext4_new_inode(handle, inode->i_sb->s_root->d_inode,
S_IFREG | 0600, NULL, inode->i_ino + 1, owner,
EXT4_EA_INODE_FL);
}
fs/ext4/migrate.c:ext4_ext_migrate() {
...
owner[0] = i_uid_read(inode);
owner[1] = i_gid_read(inode);
tmp_inode = ext4_new_inode(handle, d_inode(inode->i_sb->s_root),
S_IFREG, NULL, goal, owner, 0);
}
In fs/ext4/ialloc.c, __ext4_new_inode() then passes those 32-bit values to
i_uid_write() and i_gid_write() before calling dquot_initialize():
fs/ext4/ialloc.c:__ext4_new_inode() {
if (owner) {
inode->i_mode = mode;
i_uid_write(inode, owner[0]);
i_gid_write(inode, owner[1]);
}
...
err = dquot_initialize(inode);
}
Because make_kuid(&init_user_ns, (uid_t)-1) produces INVALID_UID (with
KID_LEGACY and value -1) rather than preserving the UUID or GUID,
qid_has_mapping() in dqget() returns false and causes dquot_initialize() to
fail with -EINVAL when quotas are enabled, or writes out the helper inode
with EXT4_ID_R_LEGACY and i_uid 0xffffffff when quotas are disabled.
Should ext4_xattr_inode_create() and ext4_ext_migrate() preserve the full
kuid_t and kgid_t owner and group when creating helper inodes for a UUID or
GUID owned file?
[ ... ]
> @@ -6006,6 +6079,40 @@ static void ext4_wait_for_tail_page_commit(struct inode *inode)
> *
> * Called with inode->i_rwsem down.
> */
> +/*
> + * An inode from before uid_r, or with in-inode xattrs in the way, may
> + * lack room for i_uid_r and i_gid_r: make it, before it gets a UUID or
> + * GUID owner or group.
> + */
> +static int ext4_make_room_for_id_r(struct mnt_idmap *idmap,
> + struct inode *inode, struct iattr *attr)
> +{
> + struct ext4_iloc iloc;
> + bool legacy = true;
> + int err;
> +
> + if (attr->ia_valid & ATTR_UID)
> + legacy = uid_is_legacy(from_vfsuid(idmap, i_user_ns(inode),
> + attr->ia_vfsuid));
> + if (attr->ia_valid & ATTR_GID)
> + legacy &= gid_is_legacy(from_vfsgid(idmap, i_user_ns(inode),
> + attr->ia_vfsgid));
> + if (legacy)
> + return 0;
> + if (!ext4_has_feature_uid_r(inode->i_sb))
> + return -EOVERFLOW;
> +
> + err = ext4_get_inode_loc(inode, &iloc);
> + if (err)
> + return err;
> + if (EXT4_FITS_IN_INODE(ext4_raw_inode(&iloc), EXT4_I(inode), i_gid_r)) {
> + brelse(iloc.bh);
> + return 0;
> + }
[Severity: Medium]
In ext4_make_room_for_id_r(), EXT4_FITS_IN_INODE() is checked without
holding EXT4_I(inode)->xattr_sem before calling ext4_expand_extra_isize()
with EXT4_EXTRA_ISIZE_UID_R.
Concurrently, paths that dirty the inode without holding inode->i_rwsem
(such as ext4_dirty_inode(), ext4_page_mkwrite(), or
ext4_end_io_rsv_work()) can call __ext4_mark_inode_dirty() ->
ext4_try_to_expand_extra_isize(), which acquires xattr_sem via
ext4_write_trylock_xattr() and sets EXT4_STATE_NO_EXPAND while xattr_sem is
held.
If ext4_expand_extra_isize() runs during that window, it checks
EXT4_STATE_NO_EXPAND before taking xattr_sem:
fs/ext4/inode.c:ext4_expand_extra_isize() {
if (ext4_test_inode_state(inode, EXT4_STATE_NO_EXPAND)) {
brelse(iloc->bh);
return -EOVERFLOW;
}
...
}
Furthermore, if ext4_expand_extra_isize() passes that check and blocks on
ext4_write_lock_xattr() while ext4_try_to_expand_extra_isize() expands
ei->i_extra_isize to sbi->s_want_extra_isize (when sbi->s_want_extra_isize
exceeds EXT4_EXTRA_ISIZE_UID_R), __ext4_expand_extra_isize() will then see
new_extra_isize < ei->i_extra_isize and return -EINVAL:
fs/ext4/inode.c:__ext4_expand_extra_isize() {
if ((new_extra_isize < ei->i_extra_isize) ||
(new_extra_isize < 4) ||
(new_extra_isize > inode_size - EXT4_GOOD_OLD_INODE_SIZE))
return -EINVAL; /* Should never happen */
}
Could this race cause ext4_make_room_for_id_r() to spuriously fail a chown
operation with -EOVERFLOW even when sufficient extra inode space is
available?
> + err = ext4_expand_extra_isize(inode, EXT4_EXTRA_ISIZE_UID_R, &iloc);
> + return err ? -EOVERFLOW : 0;
> +}
[Severity: High]
What happens here if ext4_expand_extra_isize() returns 0 without expanding
i_extra_isize all the way to EXT4_EXTRA_ISIZE_UID_R?
When an inode has in-inode extended attributes (EXT4_STATE_XATTR) that
cannot be moved out to free 36 bytes (for example, inline data or an
external xattr block without enough free space), ext4_expand_extra_isize()
-> __ext4_expand_extra_isize() -> ext4_expand_extra_isize_ea() falls back
to s_min_extra_isize (typically 32 bytes) on -ENOSPC and jumps to retry:
fs/ext4/xattr.c:ext4_expand_extra_isize_ea() {
retry:
isize_diff = new_extra_isize - EXT4_I(inode)->i_extra_isize;
if (EXT4_I(inode)->i_extra_isize >= new_extra_isize)
return 0;
...
if (error) {
if (error == -ENOSPC && !tried_min_extra_isize &&
s_min_extra_isize) {
tried_min_extra_isize++;
new_extra_isize = s_min_extra_isize;
error = 0;
goto retry;
}
goto cleanup;
}
}
When i_extra_isize is already at least s_min_extra_isize (such as 32 bytes
on an inode created before uid_r), ext4_expand_extra_isize_ea() returns 0
at the retry label while i_extra_isize is still smaller than
EXT4_EXTRA_ISIZE_UID_R.
ext4_make_room_for_id_r() then returns 0, so ext4_setattr() updates
inode->i_uid and inode->i_gid in memory to the UUID/GUID and calls
ext4_mark_inode_dirty() -> ext4_do_update_inode() -> ext4_fill_raw_inode()
-> ext4_inode_set_id_r(), which sees !legacy && !fits, returns -EOVERFLOW,
and triggers a false-positive filesystem corruption error:
fs/ext4/inode.c:ext4_do_update_inode() {
err = ext4_fill_raw_inode(inode, raw_inode);
spin_unlock(&ei->i_raw_lock);
if (err) {
EXT4_ERROR_INODE(inode, "corrupted inode contents");
goto out_brelse;
}
}
Should ext4_make_room_for_id_r() verify that i_gid_r actually fits in the
inode after ext4_expand_extra_isize() returns?
[ ... ]
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index d636b89090a24..34ac087c32dcb 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -4613,9 +4613,17 @@ static int ext4_inode_info_init(struct super_block *sb,
> sb->s_time_min = EXT4_TIMESTAMP_MIN;
> }
>
> + if (ext4_has_feature_uid_r(sb) &&
> + sbi->s_inode_size < EXT4_GOOD_OLD_INODE_SIZE + EXT4_EXTRA_ISIZE_UID_R) {
> + ext4_msg(sb, KERN_ERR, "uid_r needs inodes of at least %zu bytes",
> + EXT4_GOOD_OLD_INODE_SIZE + EXT4_EXTRA_ISIZE_UID_R);
> + return -EINVAL;
> + }
> +
> if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
> - sbi->s_want_extra_isize = sizeof(struct ext4_inode) -
> - EXT4_GOOD_OLD_INODE_SIZE;
> + /* room for the uid_r fields in new inodes only if needed */
> + sbi->s_want_extra_isize = ext4_has_feature_uid_r(sb) ?
> + EXT4_EXTRA_ISIZE_UID_R : EXT4_EXTRA_ISIZE_BASE;
[Severity: Medium]
In __ext4_fill_super(), ext4_inode_info_init() initializes
sbi->s_want_extra_isize to EXT4_EXTRA_ISIZE_UID_R, but
parse_apply_sb_mount_options(), ext4_check_opt_consistency(), and
ext4_apply_options() run right afterwards (and on remount in
__ext4_remount()) and overwrite sbi->s_want_extra_isize when the
debug_want_extra_isize mount option is specified.
Because ext4_check_opt_consistency() only checks the upper bound of
ctx->s_want_extra_isize:
fs/ext4/super.c:ext4_check_opt_consistency() {
if (ctx->s_want_extra_isize >
(sbi->s_inode_size - EXT4_GOOD_OLD_INODE_SIZE)) {
ext4_msg(NULL, KERN_ERR,
"Invalid want_extra_isize %d",
ctx->s_want_extra_isize);
return -EINVAL;
}
}
mounting or remounting a uid_r filesystem with debug_want_extra_isize
smaller than EXT4_EXTRA_ISIZE_UID_R causes __ext4_new_inode() to initialize
ei->i_extra_isize to that smaller value.
If a new inode is then created with a UUID or GUID owner or group, won't
ext4_mark_inode_dirty() -> ext4_do_update_inode() -> ext4_fill_raw_inode()
-> ext4_inode_set_id_r() return -EOVERFLOW and trigger
EXT4_ERROR_INODE(inode, "corrupted inode contents")?
> if (ext4_has_feature_extra_isize(sb)) {
> unsigned v, max = (sbi->s_inode_size -
> EXT4_GOOD_OLD_INODE_SIZE);
> @@ -5437,6 +5445,10 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
> /* HSM events are allowed by default. */
> sb->s_iflags |= SB_I_ALLOW_HSM;
>
> + /* uid_r: inodes can have UUID and GUID owners */
> + if (ext4_has_feature_uid_r(sb) && !test_opt(sb, NO_UID32))
> + sb->s_iflags |= SB_I_UID_R;
[Severity: Medium]
While __ext4_fill_super() avoids setting SB_I_UID_R when NO_UID32 is
enabled at mount time, __ext4_remount() allows enabling NO_UID32 on remount
without clearing SB_I_UID_R, and ext4_inode_get_id_r() loads UUID and GUID
owners into inode->i_uid and inode->i_gid regardless of NO_UID32.
When an inode with a UUID or GUID owner or group is dirtied and written out
in ext4_fill_raw_inode() while NO_UID32 is set, i_uid_read(inode) and
i_gid_read(inode) return 0xffffffff, and the NO_UID32 branch converts them
with fs_high2lowuid() and fs_high2lowgid():
fs/ext4/inode.c:ext4_fill_raw_inode() {
if (!(test_opt(inode->i_sb, NO_UID32))) {
...
} else {
raw_inode->i_uid_low = cpu_to_le16(fs_high2lowuid(i_uid));
raw_inode->i_gid_low = cpu_to_le16(fs_high2lowgid(i_gid));
raw_inode->i_uid_high = 0;
raw_inode->i_gid_high = 0;
}
}
Doesn't this overwrite the on-disk 0xffffffff sentinel in i_uid and i_gid
with 0x0000fffe (65534) while leaving i_uid_r_type and i_gid_r_type set to
EXT4_ID_R_UUID or EXT4_ID_R_GUID?
> +
> err = ext4_check_feature_compatibility(sb, es, silent);
> if (err)
> goto failed_mount;
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1792552161.git.jan.koester@tuxist.de?part=31
next prev parent reply other threads:[~2026-10-22 3:17 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 3:15 [RFC PATCH v2 00/41] UUID and GUID user and group ids (*_r system calls) Jan Koester
2026-10-21 3:15 ` [RFC PATCH v2 01/41] uuid: move uuid_t and guid_t into <linux/uuid_types.h> Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 02/41] uapi: add <linux/uidgid_r.h> for 128 bit capable user and group ids Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 03/41] uidgid: add uid_is_legacy() and gid_is_legacy() Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 04/41] net: sock: read sk_uid through a seqcount Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 05/41] af_unix: keep sender ids in skb->cb only when they are classic ids Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 06/41] netlink: keep classic sender ids in skb->cb Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 07/41] Bluetooth: " Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 08/41] smb: client: use __kuid_val() for the unix SIDs of the caller Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 09/41] uidgid: let kuid_t and kgid_t hold a UUID or a GUID Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 10/41] uidgid: convert between kernel ids and the ids of the *_r system calls Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 11/41] fscrypt: show the whole uid in the description of user key claims Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 12/41] keys: name per-user keyrings of UUID and GUID users by the whole uid Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 13/41] ublk: refuse unprivileged devices to UUID and GUID users Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 14/41] nfsd: don't hand out uid 0 for read layouts of UUID-owned files Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 15/41] SUNRPC: name UUID and GUID users to gssd as uid_r= Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 16/41] ecryptfs: hash daemons by kuid_hash() Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 17/41] quota: don't account UUID and GUID owners Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 18/41] fs: keep UUID and GUID owners off filesystems that can't store them Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 19/41] cred: add the *_r variants of the get/set*id() system calls Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 20/41] groups: add getgroups_r() and setgroups_r() Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 21/41] fs: add chown_r(), lchown_r(), fchown_r() and fchownat_r() Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 22/41] arch: wire up the *_r uid and gid system calls Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 23/41] statx: report UUID and GUID owners Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 24/41] shmem, ramfs: allow " Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 25/41] uidgid: parse and print ids in their text form Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 26/41] proc: show UUID and GUID ids in status, accept them for loginuid Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 27/41] audit: log UUID and GUID ids in full Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 28/41] net: add SO_PEERCRED_R, SO_PEERGROUPS_R and SCM_CREDENTIALS_R Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 29/41] signal: report the sender's UUID or GUID uid in si_uid_r Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 30/41] ipc: add IPC_STAT_R and IPC_SET_R Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 31/41] ext4: add the uid_r feature for UUID and GUID owners Jan Koester
2026-10-22 3:17 ` sashiko-bot [this message]
2026-10-21 3:15 ` [RFC PATCH v2 32/41] ext4: let uid_r be turned on while the filesystem is mounted Jan Koester
2026-10-22 3:17 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 33/41] posix_acl: support UUID and GUID entries Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 34/41] ext4: store ACLs with UUID and GUID entries on uid_r filesystems Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 35/41] Documentation: describe UUID and GUID user and group ids Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 36/41] selftests: add tests for UUID and GUID ids Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 37/41] ovl: allow UUID and GUID owners when the upper layer does Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 38/41] devpts: allow UUID and GUID owners Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:15 ` [RFC PATCH v2 39/41] ksmbd: log in UUID and GUID users and map them to SIDs Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:16 ` [RFC PATCH v2 40/41] nfsd, nfs: carry UUID and GUID owners as their text form Jan Koester
2026-10-21 17:35 ` Chuck Lever
2026-10-22 2:52 ` Takeshi Nishimura
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:16 ` [RFC PATCH v2 41/41] Documentation: uid_r: describe SMB and NFSv4 Jan Koester
2026-10-22 3:18 ` sashiko-bot
2026-10-21 3:20 ` [RFC PATCH v2 00/41] UUID and GUID user and group ids (*_r system calls) jan Koester
2026-10-21 14:26 ` Adding dreaded Windows SID-style, or. Repeating history, the bad chapters. UUID/GUIDRe: " Lionel Cons
2026-10-22 17:00 ` Casey Schaufler
2026-10-22 18:26 ` Theodore Tso
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=sashiko-outbox-180932@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anna@kernel.org \
--cc=arnd@arndb.de \
--cc=audit@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=jack@suse.cz \
--cc=jan.koester@tuxist.de \
--cc=jlayton@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=serge@hallyn.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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