[PATCH v3 2/2] hostfs: store permissions in extended attributes

[Marko Petrović]

On Tue Apr 18, 2023 at 10:31 AM CEST, Johannes Berg wrote:
Hello,
Thanks for your reply!
> Hi,
>
> On Sun, 2023-04-16 at 19:24 +0200, Marko Petrović wrote:
> > 
> > I have written the third version of the patch. Thank you for all of your
> > recommendations.
> > 
> > While writing the third patch version, I noticed that there was a
> > serious limitation of the code in second patch, namely the whole
> > xattrperm feature was available only and only as boot time flag so it
> > could not be used when hostfs was built as module since modules don't
> > have hostfs_args() function.
> > 
> > To overcome that issue, I have changed the content of
> > struct super_block -> s_fs_info to point to a struct hostfs_fs_info
> > containing the string that was previously there (to be used by old
> > functions) and the per-mountpoint use_xattr flag.
> > This allows easy extending of mount options in the future and thus
> > providing more flexibility to userspace to configure the filesystem.
> > For example, hostfs_attr, acl and noacl could be the mount options added
> > for POSIX ACLs and extended attributes in the future and if there is a
> > desire for that, append could become a mount option now too.
> > 
> > Regarding xattrperm as the kernel boot parameter, I left it available and
> > it defines the default behavior when mounting the filesystem (when
> > neither xattrperm nor noxattrperm is specified in mount options).
>
> It seems that _maybe_, similar to the 'hostfs' kernel argument, there
> should be a way to contain the set of options?
>
> What do I mean by that? I mean that today, the inside of the virtual
> machine (for lack of a better word) can only mount outside folders that
> are contained in the folder indicated by the 'hostfs' argument.
> Similarly, perhaps the "outside administrator" should be able to
> indicate that xattr permissions _must_ be used, or _must not_ be used?
Nice observation. It shouldn't be hard to do this, I can just change
the interpreted meaning of mnt_use_xattr and hostfs_fs_info->use_xattr
to comply with this behavior. Thanks for bringing this to attention.
>
> Which would imply a new kernel argument that can be configured to "force
> use", "force don't use" and "don't care", with perhaps even for backward
> compatibility the default being "force don't use"?
>
> Not sure. Anton? Richard? Any opinions?
Maybe xattrperm and noxattrperm can be kernel command line arguments
used for "force use" and "force don't use" and when none is specified,
the behavior could be "don't care" which would thus be the default.

That may also be reasonable for the purpose of backward compatibility
since the usage of extended attributes would then be specified as an mount
option and applications not aware of it would just use the old behavior
(since the extended attributes would be used only when specified in
mount options).

On the other hand, that would require a little different mounting of
root filesystem. Maybe adding rootxattrperm as a new kernel command line
argument for mounting root with "rootfstype=hostfs hostfs=rootxattrperm"
could be the solution (for when root should use extended attributes, but
the general behavior should still be "don't care")?
What are your opinions?

Best regards,
Marko Petrović