Re: [PATCH 01/14] fs_parse: add uid & gid option option parsing helpers

Jan Kara <[email protected]>
Newsgroups gmane.comp.file-systems.ext4,gmane.linux.file-systems,gmane.linux.kernel.autofs,gmane.linux.kernel.efi,gmane.linux.kernel.mm,gmane.linux.kernel.cifs
Message-ID <20240628094517.ifs4bp73nlggsnxz@quack3>
On Thu 27-06-24 19:26:24, Eric Sandeen wrote:
> Multiple filesystems take uid and gid as options, and the code to
> create the ID from an integer and validate it is standard boilerplate
> that can be moved into common helper functions, so do that for
> consistency and less cut&paste.
> 
> This also helps avoid the buggy pattern noted by Seth Jenkins at
> https://lore.kernel.org/lkml/CALxfFW4BXhEwxR0Q5LSkg-8Vb4r2MONKCcUCVioehXQKr35eHg@mail.gmail.com/
> because uid/gid parsing will fail before any assignment in most
> filesystems.
> 
> Signed-off-by: Eric Sandeen <[email protected]>

I like the idea since this seems like a nobrainer but is actually
surprisingly subtle...

> diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> index a4d6ca0b8971..24727ec34e5a 100644
> --- a/fs/fs_parser.c
> +++ b/fs/fs_parser.c
> @@ -308,6 +308,40 @@ int fs_param_is_fd(struct p_log *log, const struct fs_parameter_spec *p,
>  }
>  EXPORT_SYMBOL(fs_param_is_fd);
>  
> +int fs_param_is_uid(struct p_log *log, const struct fs_parameter_spec *p,
> +		    struct fs_parameter *param, struct fs_parse_result *result)
> +{
> +	kuid_t uid;
> +
> +	if (fs_param_is_u32(log, p, param, result) != 0)
> +		return fs_param_bad_value(log, param);
> +
> +	uid = make_kuid(current_user_ns(), result->uint_32);

But here is the problem: Filesystems mountable in user namespaces need to use
fc->user_ns for resolving uids / gids (e.g. like fuse_parse_param()).
Having helpers that work for some filesystems and are subtly broken for
others is worse than no helpers... Or am I missing something?

And the problem with fc->user_ns is that currently __fs_parse() does not
get fs_context as an argument... So that will need some larger work.

								Honza
-- 
Jan Kara <[email protected]>
SUSE Labs, CR
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.